The picture shows a simplified ordering process, the first is to submit the order, and then the payment.
For payment, the payment gateway (payment center) is generally used, and then the payment center interacts with third-party payment channels (WeChat, Alipay, UnionPay).
After the payment is successful, the payment center is notified asynchronously, the payment center updates its own payment order status, and then notifies the business application, and each business then updates its order status.
The problem that may often be encountered in this process is the order drop, whether it is a timeout and the callback notification is not received, or the program itself reports an error.
In short, due to various reasons, failure to receive the notification as scheduled and correctly process the follow-up logic, etc., will cause the user to pay successfully, but the order status on the server side is not updated.
At this time, complaints may arise, or users may make repeated payments.
Orders due to ③⑤ are called external orders, and orders caused by ④⑥ are called internal orders
In order to prevent dropped orders, here can be handled like this:
1. Add an intermediate status "paying" to the payment order. When paying for the same order, first check whether there is a payment flow with the status "paying". Of course, add a lock when paying (prepay). After the payment is completed, when the payment flow status is updated, it will be changed to "payment successful" status.
2. The payment center needs to define a timeout period (for example: 30 seconds). If the payment success callback is not received within this time range, it should call the interface to actively query the payment result, such as checking once in 10s, 20s, and 30s. If no results are found within the maximum number of queries, exception handling should be done
3. After the payment center receives the payment result, it will synchronize the result to the business system. You can send MQ or call directly. If you call directly, you need to retry (for example: SpringBoot Retry)
4. Whether it is a payment center or a business application, the idempotency of the interface must be considered when receiving the payment result notification. The message is only processed once, and the rest are ignored.
5. Business applications should also actively query payment results over time
For the overtime active query mentioned above, you can put these payment orders into a table when initiating payment, and use the scheduled task to scan
In order to prevent repeated submission of orders, it can be handled like this:
1. When creating an order, use the order information to calculate a hash value to determine whether there is a key in redis. If there is, it is not allowed to submit repeatedly. If not, generate a new key, put it in redis to set an expiration time, and then create the order.
In fact, the same operation cannot be repeated for a period of time
Attached are the best practices of WeChat payment:
