Generally, the payment gateway (payment center) is used, and then the payment center interacts with third-party payment channels (wechat, Alipay and UnionPay). After the payment is successful, the payment center will be notified asynchronously, and the payment center will update its own payment order status, and then the business application will be notified, and each business will update its own 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.
Due to ③⑤ caused by the drop order is called external drop order, by ④⑥ caused by the drop order we call it internal drop order
In order to prevent missing orders, here can be handled like this:
1. Add an intermediate state “Payment in progress” to the payment order. When the same order is paid, check whether there is a payment flow in the “payment in progress” first. After the payment is completed, update the payment flow status and then change it to “payment successful” status.
2. The payment center shall define a timeout period (for example, 30 seconds). If no successful payment callback is received within this time range, the interface shall be called to actively query the payment result, such as every 10s, 20s and 30s
3. After receiving the payment result, the payment center will synchronize the result to the business system. You can send MQ or call it directly.
4. Both payment centers and business applications should consider interface idempotency when receiving notification of payment results. Messages are processed only once and the rest are ignored
5. Business applications should also proactively query payment results over time
For the time-out active query mentioned above, the payment orders can be placed in a table when the payment is initiated and scanned with a scheduled task
To prevent the order from being submitted twice, 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, repeated submission is not allowed. In fact, the same operation cannot be repeated for a period of time
Attached wechat Pay best practices: