paypal异步回调超时或无法请求到我们的服务器解决方案

业务场景

由于我司最近接入海外业务，支付使用了paypal支付，在线上跑一段时间后频频的收到用户反馈购买商品时用户已经支付了，系统却提示用户未购买成功。这导致用户体验相当的差，也影响到了业务正常运作。

问题排查

于是我就拿用户提供的paypal交易号去查paypal商户管理平台查看用户是否已经完成了支付，结果发现用户真的完成了支付，但是我们的系统订单状态却是未支付状态，通过查看数据对比分析基于只有部分用户反馈未支付成功、其它用户都支付成功了，可以排除不是代码级别低级错误，可能有如下原因：

原因1
描述：业务系统与支付中心系统进行通信时是否延时过大，导致整个交易没有进行到底系统就报错。
结果分析：在支付中心系统与业务中心系统中未发现操作日志，可以排除。
原因2
描述：paypal服务器异步回调我们服务器时因为网络问题延迟或丢包，导致无法请求到我们的系统，造成订单是未支付状态
结果分析：我们的服务部署在国内，使用了阿里云全球CDN加速器进行加速，基于网络架构，国外某些区域请求我们服务器时可能会存在丢包或延时的情况。

解决方案

完成问题排查以后，我基本确定是原因2导致的，由于现在好大一部分用户都反馈有此类问题，所以得想一个应急方案来临时处理一下呀，于是我就有了如下2套方案：

应急方案1：开发一个小工具针对已付款的用户直接激活订单等业务信息，开发小工具时间成本在4个小时左右，而且为了保证小工具不出问题，还有经过测试人员测一轮才能交给运营使用，七七八八算下来，从开发到交到运营手上前前后后需要1天的时间，时间成本折腾不起，于是又想了另外一个方案。
应急方案2：登录paypal商户平台，点击右上角设置->选择销售工具->点击即时付款通知的更新->点击即时付款通知记录后，根据paypal交易号查看paypal异步回调交易记录，然后选择重新发送异步通知信息，该方案可行，运营可以直接使用，只需要快速写一个操作文档交给运营即可。

应急方案已经有了，但是从长远来看，我们得从根上解决问题。

长远方案1：可否改变网络架构呢？网络架构的确可以调整，但是调整成本太大。
长远方案2：既然paypal异步回调老是由于网络原因导致我们的订单业务无法成功，我们可否绕过异步回调呢？嘿嘿，当然可以啦，我们可以在paypal同步回调我们服务器时做手脚呀，在用户完成支付后点击返回商家我们就可以使用paypal携带给我们的参数再拿去验证签名如果合法则继续执行订单业务信息，我们既然有了同步回调处理逻辑了，异步回调是否可以舍弃呢？我认为还是继续保留，原因是同步回调受限于用户要点击返回商家，如果用户不返回商家则我们的同步回调就调不起来。在同步回调为调取时异步回调继续监控，双从保障，完美解决。

综上所述：长远方案2有个弊端也会导致用户购买不成功，那就是：用户支付完成以后不点击返回商家，且paypal异步回调没有调取成功，则问题就会暴露，最好的方案还是长远方案1，如果时间允许、成本允许可以考虑重构网络架构，将我们的系统根据服务点架设到具体的区域。

读者，您好，如果您有什么更好的方案欢迎在评论区回复，共同学习、共同成长哟！