轻轻一扫立刻扣款,深度解析付款码背后的原理(完结)
轻轻一扫立刻扣款,深度解析付款码背后的原理(完结)
前言
最近由于业务需求,需要开发付款码功能,该接口底层将会聚合市面上主流钱包 APP 的
叫做刷卡支付),而支付宝端产品为当面付-条支付,而有些文档会成为二维码被扫
支付。
可能有些同学对于付款码支付这个听起来很陌生,其实这个功能我们可能每天都在使用。
次扣款。
以支付宝为例,具体用户端支付流程如下:
640
付款码支付后台调用流程如下:
640
付款码支付详细版流程
官网的流程。
640
从上面的流程可以看到,付款码支付可以说是一个同步的接口,即接口同步返回扣款结
果,无需通过另外异步通知获取结果。
不过这里我们需要注意,由于涉及安全风控等问题,付款码支付过程用户端可能需要输入
密码确认支付,此时付款码接口将会返回等待用户支付。
接入时务必正确判断返回信息,若返回以下结果,代表此时用户正在输入密码。
• 支付宝:code=10003 或 code=20000
640
支付宝官方文档暂未找到相关规则,经过测试当支付金额大于 2000 ,需要输入密码。如
果有熟悉其他验密规则的同学,可以在评论区留言一下。
将会发送消息通知支付结果。但是付款码不一样,该接口是不会有消息通知的。
付/支付宝查询接口,获取支付结果。
640
撤销支付
如果在一段时间内比如 30s,轮询查询支付结果返回都是等待用户支付,或者支付交易过
程返回失败或支付系统超时,这两种情况官方文档都是建议立刻调用撤销接口撤销交易。
如果此订单用户支付失败,撤销接口将会订单关闭;如果用户支付成功,撤销接口将会订
单资金退还给用户。
也就是说撤销支付接口功能上等同与关闭订单加上退款。虽然撤销也具有退款功能,但是
两者存在比较大的区别:
支付类型限制
订单。
退款金额
撤销接口只能是全额退款,而退款接口支持传入金额,可以全额退款,也可以部分退款。
时间限制
支持当天的订单。
宝仅支持 3 个月内订单。
基于以上区别,其他正常支付的单如需实现相同功能请调用退款接口,官方文档建议仅在
异常的情况下才建议调用撤销支付接口。
另外再说一点,有些地方这个功能接口称为冲正接口,如下面工商二维码支付。
640
撤销支付相关问题
由于撤销支付,可能导致退款,也可能关闭订单,接入之前一直有些问题弄不清楚,在官
方文档处也没有查询到任何资料,没办法只好实测验证相关问题。
通道。
重复撤销
不过需要注意需要正确判断撤销的返回结果。
640
订单状态
640
也就是说,付款码订单一旦被撤销成功,再次查询订单,状态将会返回为已撤销
(REVOKED)。
的场景中,是不存在订单状态为 CLOSED—已关闭。
接下来说下支付宝的状态,支付宝文档没要给出类似的订单状态机,我根据官方一些文
档,以及一些测试结果总结出下方订单状态图。
640
所以支付宝的付款码订单一旦撤销成功,再次查询原单状态将会返回 TRADE_CLOSED。
对账文件数据
账,多账问题。
对账系统的设计方案随后会分享出来。
对账文件中。但是如果支付成功了,然后又被撤销成功,将会在对账文件中产生两笔记
录,一笔正交易,一笔反向退款记录。
但是撤销导致退款记录,我们无法仅用一个单号识别,我们需要结合另外的字段区分判
断。
加交易状态识别出一条记录是否为撤销产生退款记录。
640
件上看支付宝撤销产生退款与普通退款接口产生退款记录是一样的。
640
仔细研究对账文件可以发现一些区别,撤销导致退款记录退款批次与正交易支付宝内部订
单号是一致的。而正常退款记录,退款批次号是由商户自己上送的。所以我们可以以此筛
选出撤销产生的退款记录。
撤销失败
极端情况下,有可能产生多次撤销都失败的奇葩情况,那怎么办?
这种情况下就不用往系统自动处理方向考虑了,通过线下人工介入处理吧,毕竟这种概率
太低了。
引用知乎 @天顺 的文章中一句话:
很多时候人工保障比你动脑筋想异常中的异常如何系统自动处理来得反而高效和
低成本
这句话大家仔细品,越品越有道理!