Shulou(Shulou.com)06/03 Report--

Today, I will talk to you about how to prevent repeated prepay on the server side. Many people may not know much about it. In order to let you know more, Xiaobian summarized the following contents for you. I hope you can gain something according to this article.

Here is a simplified order flow, first submitting the order, then paying. For payment, generally go through the payment gateway (payment center), and then the payment center interacts with the third-party payment channel (WeChat, Alipay, UnionPay). After successful payment, asynchronously notify the payment center, the payment center updates its own payment order status, and then notifies the business application, and each business updates its own order status.

The problem that may often be encountered in this process is to drop the order, whether it is timeout without receiving the callback notification or the program itself reporting an error. In short, due to various reasons, the notification is not received as scheduled and the subsequent logic is processed correctly, etc., which will cause the user to pay successfully, but the order status on the server side is not updated. At this time, complaints may occur, or the user may pay repeatedly.

The drop caused by ③ ④ is called external drop, and the drop caused by ④ is called internal drop.

To prevent the loss of orders, it can be handled like this:

1. Add an intermediate status of "in payment" to the payment order. When paying for the same order, check whether there is any payment flow with the status of "in payment" first. Of course, add a lock when paying (prepay). After the payment is completed, update the payment flow status and then change it to "payment success" status.

2. The payment center should define a timeout time (for example: 30 seconds) by itself. If no successful payment callback is received within this time range, the interface should be called to actively query the payment result, for example, 10s, 20s, 30s. If no result is found within the maximum query times, exception handling should be done.

3. After the payment center receives the payment result, it synchronizes the result to the business system. It can send MQ or call it directly. If it is called directly, it needs to retry (for example: SpringBoot Retry).

4. Whether it is a payment center or a business application, the idempotent of the interface should be considered when receiving the payment result notification. The message is only processed once, and the rest is ignored.

5. Business applications should also actively query payment results over time.

For the timeout active query mentioned above, you can put these payment orders into a table when initiating payment, and scan them with timed tasks.

In order to prevent duplicate submission of orders, you can do this:

1. When creating an order, calculate a hash value with the order information, determine whether there is a key in redis, if yes, repeat submission is not allowed, if not, generate a new key, put it in redis to set an expiration time, and then create an order. In fact, the same operation cannot be repeated for a period of time

Best practices for Weixin Pay are attached:

After reading the above, do you have any further understanding of how the server prevents duplicate prepay? If you still want to know more knowledge or related content, please pay attention to the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.