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