新闻资讯

新闻资讯 媒体报道

手机没网了,却还能支付,这是什么原理?

编辑:005     时间:2020-09-07

科普支付方式

在聊付款码离线原理之前,我们先给不熟悉支付宝/微信支付方式同学先科普一下常见的两种支付方式。微信、支付宝线下支付常用支付方式有两种,一种是我们打开手机,主动扫描商家提供码牌,这种支付方式一般称为主扫支付(用户主动扫码)。以支付宝为例,付款流程如图所示:


图片来自支付宝官网

第二种则是我们打开手机,展示我们的付款码,然后商家使用扫码枪等工具获取付款码完成支付,这种支付方式一般称为被扫支付(用户被扫码)。以支付宝为例,付款流程如图所示:


图片来自支付宝官网

对于第一种方式,需要手机端 APP 扫码,然后弹窗确认付款,这种方式是没有办法在手机没有网络的情况完成支付,所以我们上文说的没有网络的情况特指付款码支付的场景。

付款码付款流程

在聊付款码离线支付的前提前,我们先来来看下付款码的整体流程,以超市购物为例,一次付款码的支付信息流如图所示:


这个过程商家后台系统是需要调用的支付宝条码支付的接口,完成支付。「由于商家后台需要在线联网与支付宝后台通讯,所以说付款码的离线支付,指的是客户端没有的网络的情况,商家端其实必须实时联网在线。」一次付款码接口调用流程如图所示:

通过上面两张图,我们整体了解付款码交互流程。付款码的技术方案其实可以分为客户端在线与离线的两种情况,下面我们来看下两种方案具体实现方式。

在线码方案

客户端在线码的方案,这个应该比较容易想到,只要支付宝/微信在登录的情况下,点击付款按钮,客户端调用后台系统的申请付款码接口。后台系统受到请求之后,生成一个付款码,然后在数据库保存付款码与用户的关系,并且返回给客户端。只要客户端在有效期内展示该付款码,就可以完成支付,否则该二维码就将会过期。使用这种方案,相对来说比较安全,因为每次都是服务端生成码,服务端可以控制幂等,没有客户端伪造的风险的。另外即使需要对付款码规则调整,比如付款码位数增加一位,我们只要调整服务端代码即可,客户端都无需升级。「不过这种方案缺点也比较明显,客户端必须实时在线联网,没有网络则无法获取付款码。」另外,现在有一些智能设备也开始支持支付宝支付,这些设备中很大一部分是没有联网的功能(比如小米手环四),那这种情况是没办法使用在线码方案。

动态口令技术原理

首先如果我们需要使用 「Google Authenticator」,我们需要在网站上开启二次验证功能,以 Google 账号为例,在设置两步验证的地方可以找到如下设置:


当我们点击设置,将会弹出一个二维码,然后使用 「Google Authenticator」 APP 扫码绑定。

当我们绑定之后, 「Google Authenticator」 APP 将会展示动态码。我们来解析一下这个二维码,对应下面这个字符串:

otpauth://totp/Google%3Ayourname@gmail.com?secret=xxxx&issuer=Google 
上面的字符串中,最重要就是这一串密钥 secret,这个是一个经过 「BASE32」 编码之后的字符串,真正使用时需要将其使用「BASE32」 解码,处理伪码如下:
original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret))) 
「这个密钥客户端与服务端将会同时保存一份,两端将会同样的算法计算,以此用来比较动态码的正确性。」我们以客户端为例,生成一个动态码,首先我们需要经过一个签名函数,这里 **Google Authenticator **采用的 「HMAC-SHA1」,这是一种基于哈希的消息验证码,可以用比较安全的单向哈希函数(如 SHA1)来产生签名。签名函数伪码如下:
hmac = SHA1(secret + SHA1(secret + input)) 
上面函数中的,input 使用当前时间整除 30 的值。
input = CURRENT_UNIX_TIME() / 30 
这里时间就充当一个动态变参,这样可以源源不断产生动态码。「另外这里整除 30,是为了赋予验证码一个 30 秒的有效期。」这样对于用户输入来讲,可以有充足时间准备输入这个动态码,另外一点客户端与服务端可能存在时间偏差,30 秒的间隔可以很大概率的屏蔽这种差异。画外音:这个有效时间其实很考量,如果比较长,安全性就差。如果比较短,用户体验就很差,不容易输入准备。经过 「HMAC-SHA1」 签名函数以后,我们得到一个长度为 40 的字符串,我们还需要将其转化为 6 位数字,方便用户输入。处理的伪码如下:
four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]
large_integer = INT(four_bytes)
small_integer = large_integer % 1,000,000 
完整的算法伪码如下:
original_secret = xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx
secret = BASE32_DECODE(TO_UPPERCASE(REMOVE_SPACES(original_secret)))
input = CURRENT_UNIX_TIME() / 30 hmac = SHA1(secret + SHA1(secret + input))
four_bytes = hmac[LAST_BYTE(hmac):LAST_BYTE(hmac) + 4]
large_integer = INT(four_bytes)
small_integer = large_integer % 1,000,000 
当客户端将动态码上传给服务端,服务端查询数据库获取到用户对应的密钥,然后使用同样的算法进行处理生成一个动态码,最后比较客户端上传动态码与服务端生成是否一致。

最后

最后总结一下,我们平常使用付款码支付,其实原理就是商家端获取我们手机 APP 付款码(「其实就是一串数字」),然后后台调用支付宝支付接口完成扣款。这个流程商家端后台程序必须联网在线,但是对于我们客户端来讲可以在线,也可以离线。如果我们客户端在线,那就可以通过服务端向客户端发送付款码,这种方式更加安全,灵活,但是对于弱网环境下,体验就很差。如果我们客户端没网,那就通过客户端通过一定算法生成付款码,服务端收到经过相关校验,确认是哪个用户,确认码有效性,并且完成扣款。这种方式,适合客户端没有网络的情况,不过相对不灵活,且安全性稍差。嘿嘿,了解原理,有没有觉得还是挺有意思的~下次排队付款钱,如果手机没网,不要担心尴尬,放心拿出手机付钱~

本内容属于网络转载,文中涉及图片等内容如有侵权,请联系编辑删除

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

回复列表

相关推荐