Preventing Order Loss and Duplicate Submissions in Payment Systems

Overview of a simplified order process: submit order then pay via a payment gateway that interacts with third‑party channels (WeChat, Alipay, UnionPay).

After payment, the gateway sends asynchronous notifications to update order status; failures in receiving or processing these notifications cause “order loss”, leading to unpaid orders not reflected in the system, complaints, or duplicate payments.

Order loss is classified as external (caused by timeout or gateway errors) or internal (caused by application errors).

To prevent order loss, the article suggests:

Introduce an intermediate “paying” status and lock the pre‑pay process; update to “paid” after successful payment.

Define a timeout (e.g., 30 seconds) in the payment center; if no callback is received, actively query the payment result at intervals and handle exceptions after the maximum number of retries.

Synchronize payment results to business systems via MQ or direct calls with retry mechanisms (e.g., Spring Boot Retry).

Ensure idempotency of notification handling so each message is processed only once.

Business services should also actively query payment results on timeout.

To avoid duplicate order submissions, compute a hash of the order data and store a key in Redis with an expiration; reject submissions if the key exists, otherwise create the order and set the key.

The article also shares a Spring Boot + MyBatis Plus + Vue 3.2 + Vite + Element Plus demo blog project with source code links on GitHub and Gitee, and provides a WeChat Pay best‑practice diagram.

Finally, the author encourages readers to share the article and join a community group for further architectural discussions.