支付宝支付回调的坑点

梳理一下对接支付宝支付时回调踩过的一个坑。

问题

时间过了一年再次收到一条来自支付宝的回调信息，结果被处理成支付成功的回调（还好后面的逻辑有对订单状态进行校验，因此没有流程上的漏洞）。

支付宝支付的回调

通知触发条件

触发条件名	触发条件描述	触发条件默认值
TRADE_FINISHED	交易完成	true（触发通知）
TRADE_SUCCESS	支付成功	true（触发通知）
TRADE_CLOSED	交易关闭	true（触发通知）
WAIT_BUYER_PAY	交易建立	false（不触发通知）

从上表可得出，当支付宝交易单的状态被设为 TRADE_FINISHED/TRADE_SUCCESS/TRADE_CLOSED 时，都会触发一次回调通知

• TRADE_SUCCESS
  TRADE_SUCCESS 的通知触发条件是商户签约的产品支持退款功能的前提下，买家付款成功

• TRADE_FINISHED
  TRADE_FINISHED 的通知触发条件是：

  • 1、商户签约的产品不支持退款功能的前提下，买家付款成功；
  • 2、商户签约的产品支持退款功能的前提下，交易已经成功而且已经超过可退款期限。

通知的地址

通知的地址是调用 alipay.trade.create （统一收单交易建立接口）时指定的回调地址 notify_url

问题剖析

一年以后又收到一条通知，剖析日志咱们发现：

1. 订单恰好是通知消息日期的一年前
2. 通知里有两个参数 trade_status=TRADE_FINISHED&refund_fee=0.00，也就是这个通知是由 TRADE_FINISHED 状态触发的
3. 查验后台设置的可退款期限：一年
4. 实证结论——这个问题是 TRADE_FINISHED 通知触发条件的第二种状况致使的

支付宝方面的问题：

1. alipay.trade.refund 统一收单交易退款接口 没有说起退款存在回调的状况。而事实上退款以后(不管是全额仍是部分)，都会触发一次异步通知
2. 支付宝的回调通知数据结构很是像，若是此次咱们不是在自身的订单状态上预先作判断，可能此次咱们遇到的问题会致使财务风险

总结

综上所述，支付宝支付的文档虽然很全，可是写得很乱，不少重要的点常常再也不重要的地方重点说明。对接的时候仍是要仔细且多考虑几个方面，尽可能编写健壮的有必定程度容灾能力的代码。

参考

https://opendocs.alipay.com/a...
https://opendocs.alipay.com/o...