在股票基金大跌期间，支付系统面临高压力，20号出现网络异常导致订单状态错误。问题在于支付接口请求未返回结果时，系统已将订单标记为失败，而三方确认支付成功。正确的支付结果处理应依赖于三方回调，并通过定时查询和T+1/T+0对账来确保一致性，必要时进行调账操作，以保障用户体验。
20号，股票基金行情大跌，所谓，高位买入，天台见；每当大跌时，交易量都会陡增
熟悉小R的朋友应该知道，小R目前做支付系统，支付系统是与钱打交道最多系统之一，所以每次大跌时，都要格外的注意，然而，世事难料，20号遇到了网络异常导致的订单失败的问题
这个问题很奇怪，我们内部的订单状态是失败的，但是询问三方，三方说支付单是成功的，于是开始排查日志
通过日志可以看到我们的请求接口还未返回结果，然后支付回调就进来了
我们可以看到我们这边的代码，网路异常和系统异常都是将订单置为失败状态，并且更新了订单的结果，当然这段代码是有问题的（不是小R写的），导致了我们更新了两遍订单的状态，第一次是支付请求还未返回结果就已经回调成功了，然后我们这边等待超时了，将订单置为失败了，所以说问题点已经明确了。
** 那么支付结果正确的做法呢？**
- 我们的支付订单在支付接口时，除非是我们内部系统的异常，不能更改订单的状态
- 支付结果需要有三方的回调，这个结果一般是准确的
- 支付中间状态需要定时的查询三方的结果
- T+1或者T+0对账系统，和第三方系统对账，如果对方是成功的，我们这边是失败的，那就需要进行调账了，对用户的体验不是很好
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
