《移动端支付系统如何设计有效地防重失效机制？》阅读心得

　　我们平时在通过App购物时支付的一瞬间实际上要经历很复杂的流程，比如点外卖支付的过程：用户在点外卖的过程中选择微信支付后，App会将支付请求发送给外卖后台系统。支付系统处理外卖平台业务后台发送过来的支付请求，记录其业务订单号并生成对应支付系统自身的支付流水号。支付系统调用微信统一下单接口进行预支付，并同步得到微信支付返回的预支付订单信息。然后支付系统将预支付信息同步给调用方—外卖业务后台，外卖业务后台再同步给外卖App。外卖App会根据预支付订单信息通过客户端支付SDK唤起微信支付客户端，由用户操作微信支付客户端直接向微信支付发起付款动作，微信支付会通过循环调用的方式主动将支付结果回调给支付系统，再由支付系统回调给外卖业务系统，最后在用户直接感知前由App主动查询外卖业务系统订单支付状态。在点外卖后付款了，微信也提示支付成功了，但是外卖App却始终不显示点餐成功，只能打客服投诉，各种麻烦。这就是你的操作重复多次但是是失效的操作。

  作者针对这个问题，欸出了几个解决方案：异步补偿机制。是支付流程按照正常的流程走，通过采用旁挂定时的方式扫描系统中一定时间策略范围内的pengding状态的订单，通过微信提供的订单查询接口主动轮询，一旦支付状态查询到终态即刻触发系统回调，完成支付订单及业务逻辑的补偿；另一方面，如果pengding状态订单通过轮询方式没有查询到最终状态则需要设置一定的重复轮询策略，例如5分钟、10分钟、20分钟、1小时、3小时、8小时、24小时这样，并在超过策略规定的时间及轮询次数后将支付流水更新为失效终态，并提供订单查询接口供业务平台完成自身业务订单逻辑的更新。但是如果采用这个方案会遇到三种情况：（1）用户最终未支付，则系统安装一定的轮询机制进行后续的订单失效处理即可；（2）、用户完成了支付，支付系统迟迟收不到微信的回调，通过逐步轮询的方式系统也会进行后续的订单回调补偿；（3）则是用户当时并未及时支付，在订单失效前的某个时间，用户可能会选择重新付款，因为此时支付系统订单并未失效，会处于支付中状态，触发防重机制，无法再次发起付款；

    

　　异步补偿机制有很多缺陷，作者提出了另一种方案。采用两种订单号：商户订单号：业务系统发起的向支付系统发起支付请求是生成的在商户系统中唯一标识一笔订单的标记。支付订单号：业务系统向支付系统发起支付请求后，支付平台本身生成的系统唯一标识一笔支付流水的标记，并且是支付系统与第三方支付渠道交互的唯一流水标识。支付系统内部采用1:3（举例）的订单模型，即1笔业务订单号可以对应支付系统3笔支付订单流水，并且每笔支付流水允许被发起的条件是上笔支付流水数据库订单状态是未支付成功，并且需要在当前这笔支付流水重新生成后将上笔支付流水放入订单动态实效队列，进行快速失效处理。超过3次时间间隔超过30s（策略可以根据业务实践进行动态调整）还未完成支付的情况，系统基本可以认定属于恶意点击行为，可以直接拒绝此笔业务订单重新发起支付了。 

　　用手机支付是一件很日常的事情，因为支付是一件很严谨的事情，所以支付机制是否完善非常重要。在这里针对支付过程中可能出现的各种错误，作者给出了两种解决方案：异步补偿机制，一个商户订单号对应多个支付订单号。