支付宝异步通知接口思考与实现
对接支付的思考
在业务系统中,对接支付宝支付时。关注到了支付宝的回调通知设计,针对支付宝的异步回调设计,可以抽象出两个系统对接时,如何保证双方的数据一致性的方案。因此针对支付宝支付系统的异步通知文档思考如何实现这种双方的数据一致性方案。
异步通知特性
客户端程序执行完后必须返回 success。如果商户反馈给支付宝的字符不是 success 这 7 个字符,支付宝服务器会不断重发通知,直到超过 24 小时22 分钟。一般情况下,25 小时以内完成 8 次通知(通知的间隔频率一般是:4 m、10 m、10 m、1 h、2 h、6 h、15 h)
可以看到最核心的就是异常的补偿机制,因此如何从给定示例中,提炼思考出一个合理的对接补偿方案是本次思考的重点。当然,实现的方式可以有很多种,本文只针对我自己思考的方案进行一个简单的demo实现。
梳理业务
支付接口
我们的业务接口以支付接口为例子,提供给调用放创建支付订单的能力,通过该接口可以发起一次付款,同时根据调用地方提供的信息,异步的通知调用方,业务的执行是否成功。
定时补偿机制
系统需要考虑相关定时补偿机制,有可能因为网络问题,异步通知没有到位,因此需要利用相关定时任务框架,针对未通知成功的业务数据做通知补偿,直到超过设置的最大阈值时间,对此订单做特殊标记,方便后续业务处理。
demo思路
调用方
调用方提供两个接口
一个用于提交支付请求
一个接口用于接受回调通知
用静态变量模拟数据库操作
服