当前位置：网站首页>The server prevents repeated payment of orders

The server prevents repeated payment of orders

2022-06-11 14:58:00 【Ant】

The server prevents repeated payment of orders

The figure above shows a simplified order placing process , The first is to submit the order , Then there's the payment . If you pay , It's usually through the payment gateway （ Payment center ）, Then the payment center and the third party payment channel （ WeChat 、 Alipay 、 UnionPay ） Interaction , After the payment is successful , Asynchronous notification to payment center , The payment center updates the status of its own payment order , Then inform the business application , Each business updates its order status .

In this process, we often encounter the problem of dropping orders , Whether it's timeout or not receiving callback notification , Or the program itself reports an error , In short, for various reasons , Didn't receive the notice as scheduled and handle the follow-up logic correctly, etc , Will cause the user to pay successfully , But the order status on the server side has not been updated , At this time, there may be complaints , Or users pay repeatedly .

from ③⑤ The resulting drop is called external drop , from ④⑥ The loss of orders caused by this is called internal loss of orders

How to prevent missing orders

Add intermediate status

Payment orders add an intermediate state “ In the payment ”, When the same order goes to pay , Check to see if the status is “ In the payment ” Payment flow , Of course, pay （prepay） Put a lock on it . After the payment is completed, when the payment flow status is updated, it will be changed to “ Successful payment ” state .

Play the role of locking

Define timeout

The payment center has to define a time-out （ such as ：30 second ）, If the payment is not received within this time frame, the callback will be successful , Then the interface should be called to actively query the payment result , such as 10s、20s、30s Check it out , If no result is found within the maximum number of queries , Exception handling should be done .

Synchronize payment results

After the payment center receives the payment result , Synchronize the results to the business system , Can send MQ, It can also be called directly , If you call it directly, try again （ such as ：SpringBoot Retry）.

Consider interface idempotency

Whether it's payment centers , Or business applications , When receiving payment result notification, we should consider the idempotency of the interface , Messages are processed only once , The rest is ignored

Active inquiry of payment results

Business applications should also take the initiative to query payment results over time , Overtime active query can put these payment orders into a table when initiating payment , Scan with timed tasks .

In order to prevent duplicate order submission , You can do this ：