Small Hub guide:

The author gives the idea, also has the diagram, see how others do, ha ha

My official account: MarkerHub, Java website: Markerhub.com

More selected articles please click: Java notebook daq.md

Author: crazy noble son

Source: cnblogs.com/cjsblog/p/14516909.html

An overview of the

Here is a simplified ordering process, first submitting the order, then paying. For payment, the payment center usually goes through the payment gateway (payment center), and then the payment center interacts with the third-party payment channels (wechat, Alipay, UnionPay). After the payment is successful, the payment center is notified asynchronously, and the payment center updates its payment order status, and then the business application is notified, and each business updates its order status.

Often may encounter in the process of this problem is single, you did not receive correction notice, either the timeout or program error, in brief for all kinds of reasons, not received notice and correct handling subsequent logic, etc., can cause users to pay a success, but the server side order status update, might have an complaints at this time, Or the user pays twice.

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

In order to prevent order drop, here can be handled like this:

1. Add an intermediate state “payment” to the payment order. When the same order is paid, first check whether there is a payment flow with the state “payment”, of course, a lock should be added when paying (prepay). When the payment flow state is updated after the payment is completed, it will be changed to the “payment succeeded” state.

2. The payment center should define a timeout period (for example, 30 seconds). If no payment success callback is received within this time range, it should call the interface to actively query the payment result, such as checking once for 10s, 20s or 30s

3. After receiving the payment result, the payment center will synchronize the result to the business system, which can be sent to MQ or directly called. If called directly, it will be weighted trial (such as SpringBoot Retry).

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

5. Business applications should also take the initiative to query the payment results after timeout

The active query for the timeout mentioned above can place the payment orders in a table at the time the payment is initiated and scan them with a scheduled task

To prevent duplicate orders, do this:

1. When creating an order, use the order information to calculate a hash value and determine whether there is a key in redis. If there is a key, repeat submission is not allowed. You can’t do the same thing over a period of time

Attached is the best practice of wechat Pay:

PS: If you think my share is good, you are welcome to click like and watch.

Recommended reading

Java notebook encyclopedia

Great, this Java website, what projects! https://markerhub.com

This B station UP main, the Java is really good!