第三方支付异步通知的陷阱

  用户下单后调用第三方支付付款,然后接收第三方支付的异步通知,以便确认支付是否成功。
如下图
交互时序图

  但异步通知可能由于网络原因,或者应用服务崩溃没有接收到。为了应对这种情况需要后台创建一个定时任务去调用第三方接口,主动查询支付结果。这种情形下就涉及并发的问题,可能后台定时任务跟异步通知同时收到了支付成功结果,同时对响应数据进行处理。通常通过加锁来避免这种问题。
  到了这里一切看起来很美好。代码提交后在测试环境顺利通过。由于测试环境情形单一,测试用例不够,异步通知总是成功的,做为备用手段的后台定时任务没有被测试覆盖到就进入了生产环境。后台定时任务的逻辑有可能是错的,而由于生产环境配置了负载平衡,保证了高可用,直到很久都不会发现定时任务的错误。笔者就遇到过在长达一年的时间里定时任务从来就不起作用。
  所以开发要在qa阶段跟测试人员紧密配合,保证每个测试用例都覆盖到,比如关掉异步通知服务,看定时任务是否能正确处理。直到有一天我发现其他部门一位同事采用了一个很有创意的做法,既然异步通知不靠谱,干脆就不要,完全靠后台定时任务主动查询第三方支付结果,然后进一步处理。

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 3
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值