三方支付接口之异步代扣接口的正确开发方法(线上填坑的总结)

前几天的新坑，还热乎着呢，赶紧拿来给大家分享一下.我相信不认真看我的文章，你如果做这个功能，会有99%的挖坑的可能，哈哈！

声明：我这里都是用一些简单流程，简单表等做一个设想，实际业务场景会比举例复杂很多！

先列几个名词：

表 t_order_pay 有个支付状态pay_state 有这么几个值 

I:init 初始状态

U:unknown 未知（处理中）状态

S:success 成功状态

F: fail 失败状态

用户在购买商品的时候，支付结果显示未知，但是购买商品状态已经是发货中. 导致我们的结果，跟实际代付的结果不一致!

发生这个问题的原因是：

我先上图哈！

0.数据入库状态 为I

1.请求代扣（耗时比较长或者网络问题导致）

2. 在第1步还在等待的时候，回调请求进来了,把状态I -> S，通知商家发货

3.第1步在等了好长时间后超时了，处理处理把状态修改为 U （注意，这里跟本没有检查库里的原来状态，直接修改为了U）

最终成我们上在说的状态不一致的结果！！

上重点：正确的处理方式

1.不要幻想，回调一定发生在请求之后！！

2. 每次一定要带上原状态值的条件，第三部的处理应该是update t_order_pay set pay_state = U where  pay_order=XXX and pay_state = I  并且在必要时（看业务）通过update后影响的行数做后续处理！

 

这里更多的是提醒大家，在设计程序的时候要多考虑异常情况，错误情况发生后程序怎么处理。

我看过太多人。处理问题，只有成功，失败！跟本没有异常，超时等处理逻辑，一上线就是各种问题！！