How to Prevent Duplicate Payments in E‑Commerce: Proven Strategies

Why Orders Get Duplicate Payments

Duplicate payments caused by lack of idempotency

When a user clicks the pay button repeatedly, each click can generate a new payment transaction and QR code, leading to multiple successful payments if the system does not enforce idempotency.

Duplicate payments caused by lost orders ("掉单")

External lost order: the third‑party payment platform does not synchronize the payment status to the shop in time. Internal lost order: the payment service fails to update the order service or the client does not fetch the latest order status.

When users see that their order is still unpaid after they have paid, they may place another order, causing a duplicate payment.

Duplicate payments caused by multiple channels

Users may try different payment methods (e.g., Boleto then PayPal) for the same order, or switch between wallets (e.g., WeChat Pay then Alipay) and complete both, resulting in two successful payments.

How to Prevent Duplicate Payments

Locking

Both the "apply payment" and "payment callback" steps should acquire a lock at the order level to prevent concurrent duplicate operations. Distributed locks such as Redis locks are commonly used.

Cache Results

After a successful payment request or callback, cache the result. Subsequent payment attempts should first check the cached payment status.

Cancel In‑Progress Payment Flow

If a user attempts to pay again while a previous payment is still in the "paying" state, the system should cancel the in‑progress transaction before creating a new one.

Refund Already‑Paid Transactions

If a new payment is initiated while an earlier transaction is still pending and the third‑party cannot cancel it, allow the new payment but refund the earlier successful transaction after confirming the final status.

Active Polling & Retry to Prevent Lost Orders

Active polling for external lost orders

If a callback is missing or delayed, the payment service should actively query the third‑party after a short interval (e.g., 3 seconds) until the final status is obtained.

Scheduled task polling : Scan payment‑in‑progress records periodically and query their status. Drawbacks include database load and inflexible intervals.

Delayed‑message polling : Send a delayed message after payment initiation; if the final status is still unknown, resend another delayed message. Reduces DB pressure but adds implementation complexity.

Sync + async to prevent internal lost orders

After receiving an async callback or completing a poll, the payment service must notify the order service. Use synchronous calls with retry logic and asynchronous messages (e.g., via a message queue) to improve reliability.

Pull: client periodically queries order status after returning from the payment page.

Push: server pushes updates via WebSocket for web or third‑party push services for mobile apps.

Keep Client Payment Within the App

From both product and technical perspectives, the client should avoid external redirects. Web and app pages should embed the payment UI when possible; PC should display a QR code generated by the payment service instead of jumping to a third‑party site.

Modern Alipay already supports in‑app payments without launching an external wallet, improving user experience and payment success rates.

Reference: Server‑side techniques for preventing duplicate payments.