Preventing Order Loss and Duplicate Submissions in Payment Systems

At the beginning the article promotes a free programmer book that can be obtained by replying with a specific keyword.

It then shows a simplified order process: first submit the order, then proceed to payment.

During payment the flow usually goes through a payment gateway, which interacts with third‑party channels (WeChat, Alipay, UnionPay). After a successful payment the gateway sends an asynchronous notification to the payment center, which updates its own order status and then notifies the business application to update its order status.

The article points out that order loss can occur: external loss caused by timeout or missing callbacks, and internal loss caused by program errors, leading to situations where the user has paid but the server has not updated the order.

To prevent order loss, several measures are suggested: 1) Add an intermediate status "paying" and lock the pre‑pay operation; after payment succeeds, change the status to "paid". 2) Define a timeout (e.g., 30 seconds) in the payment center and actively query the payment result if no callback is received, with retries at 10 s, 20 s, 30 s. 3) After receiving the payment result, synchronize it to the business system via MQ or direct calls, adding retry logic such as SpringBoot Retry. 4) Ensure idempotency in both the payment center and business applications so that each notification is processed only once. 5) Business applications should also actively query the payment result on timeout.

For preventing duplicate order submissions, the article recommends generating a hash of the order information, checking Redis for an existing key, and only allowing the order to be created if the key does not exist, with an expiration time to limit the window for duplicate attempts.

Finally, the article includes a QR code for obtaining the free book and a list of recent technical articles as additional resources.