目前我看到的加密货币的支付主要是通过dApp的形式:
- 钱包内置浏览器访问:这类钱包大部分是手机app
- 经过PC浏览器访问:这类钱包大部分是浏览器的插件
对于传统网站产品而言,要接入对加密货币的支持,需要通过引入钱包sdk或dApp框架来实现。此时,限于当前还没有一统江湖的跨链框架,一个网站就要面对不同钱包、不同dApp框架的选择了。另外,不同的链,代码逻辑也是不同的,那么,能不能简化网站的负担呢?而谁最擅长这些,当然是那些钱包了。
前提
只谈支付;不谈dApp生态。
传统的支付案例
- 点击跳转到支付平台,付完款再跳转回来 ---- 忽略
- 网站提供一个二维码,用户打开支付宝、微信直接扫码。
问题来了,我们能不能参考第二种呢?或者说,通过第二个方案引入加密货币支付,安全风险在哪?
设想
- 请求支付的json数据,结构其实可以很简单:
{
wallet/provider, // 请求的钱包
coin, // 请求的货币
amount, // 请求支付的金额
gas, // 可以接受的gas费用
orderId, // 发起的订单ID
// 其它内容
}
- 网站将这段json数据生成二维码,展示
- 用户使用钱包扫码。
- 钱包App对数据进行验证。
- 用户自行选择是否支付。
- 支付成功,返回交易hash等内容;支付失败,返回失败信息;拒绝支付,返回禁止信息
- 支付成功的情况下:网站绑定订单与交易hash,定时查询(向链上的有关网站查询)、更新(网站服务器的数据库)、显示(前端)交易状态
优点
- 网站不需要研究各类sdk;不需要担忧某个sdk不再更新(我看了Nervos Grants 获批项目一览,某些都小一年不更新了
)
- 网站可能都不需要招聘一个懂区块链开发的新员工?
- 网站的业务逻辑不会发生重大改变
- 网站可以自行选择支持哪些代币
缺点与安全隐患?
- 二维码伪造的可能性?
现有的钱包都在玩defi或dApp,谁会先回归本心:支付?
Binance Pay?
参考:库
schmich/instascan:ckb.pw也可以扫码了?
参考:规范
Payment Method Identifiers
payment-request: TR doc, github
Tokenized Card Payment
webpayments