Preventing Order Loss and Duplicate Submissions in Payment Systems

Overview

As shown in the diagram, a simplified order process consists of submitting an order followed by payment.

Payments typically go through a payment gateway, which interacts with third‑party channels such as WeChat Pay, Alipay, or UnionPay.

After a successful payment, an asynchronous notification updates the payment center’s order status, which then notifies the business application to update its own order status.

Common problems in this process include lost orders caused by timeout‑missing callbacks or program errors, leading to situations where the user has paid but the server has not updated the order status.

Consequences may include user complaints or duplicate payments.

Lost orders caused by steps 3 and 5 are termed external lost orders, while those caused by steps 4 and 6 are internal lost orders.

How to Prevent Lost Orders

Add an intermediate state "Payment In‑Progress" to the payment order. When the same order attempts payment, first check for a record in this state and lock the pre‑pay operation. After payment completes, update the record to "Payment Successful".

The payment center should define a timeout (e.g., 30 seconds). If no success callback is received within this window, actively query the payment result at intervals (e.g., every 10 s, 20 s, 30 s). If the result remains unknown after the maximum attempts, handle it as an exception.

When the payment center receives the result, propagate it to the business system via MQ or direct calls; direct calls should include retry mechanisms such as SpringBoot Retry.

Both the payment center and business applications must ensure idempotency when handling payment notifications, processing each message only once and ignoring duplicates.

The business application should also perform timeout‑driven active queries for payment results.

For the active‑query timeout strategy, place pending payment orders into a dedicated table and use a scheduled task to scan and query them.

How to Prevent Duplicate Order Submissions

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, then proceed with order creation.

This effectively prevents identical operations within a short time window.

WeChat Pay Best Practices (Illustrated)

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

文明发言，以 交流技术 、 职位内推 、 行业探讨 为主

广告人士勿入，切勿轻信私聊，防止被骗

加我好友，拉你进群

点下方的 ❤ 支持我们，非常感谢！