Prevent Duplicate Charges When Checkout Retries a Payment

A disabled Pay button covers only one browser session

A user can open the same checkout in two tabs. A network client can also retry a request after the store has already received it. Give each intended payment attempt a stable identity on the server and persist it before calling the processor. Bind that identity to the store account, order, amount, currency, and operation.

Retry the same intention with the same identity

Use the gateway’s documented duplicate-protection or idempotency mechanism when it exists. Keep the first gateway reference and result with the attempt. If the user changes the cart total or switches methods, confirm the previous attempt’s status before creating an attempt for the revised order.

Treat a timeout as an unresolved result

A timeout shows the response did not arrive. The gateway might still have accepted the request. Recover through the documented status lookup or notification flow before permitting another capture. Keep payment completion and fulfillment transitions safe to repeat independently.

Prove duplicate protection before launch

• Two simultaneous requests for one attempt leave one effective charge.
• A retry after a response timeout returns or reconciles the original result.
• A duplicate or delayed event does not send a second order confirmation or release a second shipment.