wr410
2017-10-10 21:32:48 +08:00
简单说吧！
条码支付其实格式上是有潜规则的，基本上是前 2 位用来识别这个条码属于哪个支付公司的。因为有很多聚合支付的商户，具体举例：麦当劳、全家，统一入口扫码，自动路由去请求支付授权。
所以，第一种，商户联机核销的条码。这种条码除了标识头以外，中间大概会分成 token 类似于挑战码，后面几位应该是类似于应答值。
上面有人说的一次性口令的实现其实是不严谨的，因为单纯一次性口令的前提是必须知道对方的身份。否则，给你一串条码你去几亿用户里比对？
那么如何从几个数字的条码里识别用户？这才是条码支付的核心。那么就必须提前把身份信息注册到条码里，也就是说客户端在联机的时候，预先向服务器里申请 token，这样某一个 token 被谁申请了，服务器自然就记录了。当然这还不足，如何鉴权，那就必须在服务器上和客户端里进行相同的操作，无论是 HMAC 还是预共享密钥，这个随便了，得出的结果就是后面几位的应答值。
当然，十来位的条码肯定是不足的，那么 token 段必然是多用户共享的，也就是一个 token 是可能被多个用户一起注册的，但是我们可以从 token 里知道有哪些用户在用，然后通过检索每个用户的应答值就可以完成鉴权动作了。所以这里就存在一个风险，一个 token 最大同时共享给多少人可以控制在可接受的风险范围？这些就是数学问题啦。
第二种，双方离线的二维码。
这个其实就是和公交卡一样的原理，感觉没什么可说的。大家有共同的密钥或者基于 PKI 的鉴权，生成账户支付码（无外乎就是金额、账号之类的，需要时效性就再加一个有效期），设备检查通过就可以了。反正要预先充钱，事后再记账罢了。
以上均为个人想法，欢迎探讨。