Backend Development 5 min read

Preventing Order Loss and Duplicate Submissions in Payment Systems: Best Practices

The article explains common causes of order loss and duplicate submissions in payment workflows, distinguishes external and internal loss, and provides concrete backend strategies such as intermediate payment states, timeout queries, idempotent handling, retry mechanisms, and Redis‑based deduplication to ensure reliable order processing.

Top Architect
Top Architect
Top Architect
Preventing Order Loss and Duplicate Submissions in Payment Systems: Best Practices

Overview: The simplified order flow starts with order submission followed by payment through a payment gateway, which interacts with third‑party channels (WeChat, Alipay, UnionPay). After a successful payment, an asynchronous notification updates the payment center, which then notifies business applications to update their order status.

Common issue: Order loss occurs when callbacks are missed or processing errors happen, leading to a situation where the user has paid but the server has not updated the order status, potentially causing complaints or duplicate payments.

External order loss is caused by steps 3 and 5, while internal loss stems from steps 4 and 6 in the flow.

Prevention measures for order loss:

1. Add an intermediate state "payment in progress" to the payment order. When the same order attempts payment, check for a "payment in progress" record and lock the pre‑pay operation. After payment succeeds, update the record to "payment successful".

2. Define a timeout (e.g., 30 seconds) in the payment center. If no success callback is received within this window, actively query the payment result at intervals (10 s, 20 s, 30 s). If the maximum number of queries is reached without a result, handle the exception.

3. After receiving the payment result, the payment center should push the result to business systems via MQ or direct calls, with retry logic (e.g., SpringBoot Retry) for direct calls.

4. Ensure idempotency in both the payment center and business applications when processing notifications, so each message is handled only once.

5. Business applications should also perform proactive timeout queries for payment results.

6. Store pending payment orders in a dedicated table and use a scheduled task to scan and query their status.

Prevention of duplicate order submission:

1. When creating an order, compute a hash of the order information and check Redis for an existing key. If the key exists, reject the duplicate submission; otherwise, create a new key with an expiration time and proceed with order creation.

Attached are WeChat payment best‑practice diagrams:

backendRedisbest practicesIdempotencypaymentOrder Management
Top Architect
Written by

Top Architect

Top Architect focuses on sharing practical architecture knowledge, covering enterprise, system, website, large‑scale distributed, and high‑availability architectures, plus architecture adjustments using internet technologies. We welcome idea‑driven, sharing‑oriented architects to exchange and learn together.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.