ARTICLE 04
The Customer Clicked Pay Twice—Will They Be Charged Twice?
How to prevent the same operation from being executed more than once
October 20, 2026 / 5 min read
Imagine a customer clicking Pay in an online store. The connection is slow, no result appears, and the customer clicks the button again.
What happens if the server receives both requests and processes the payment twice?
The customer could be charged twice even though they intended to make only one purchase.
This is one of the important failure scenarios I learned to consider when designing order and payment systems.
Where is the problem?
In a simple design, the backend may treat every HTTP request as a new operation.
Requests can be repeated for many reasons: a user clicks more than once, the connection drops, or a client retries automatically after a network failure.
This is where idempotency becomes important. Repeating the same operation should not repeat its effect.
How do we handle it?
One solution is an idempotency key: a unique operation identifier sent with the request and reused when the same operation is attempted again.
When the server receives the request, it follows a controlled sequence:
- Validate and check the operation key safely.
- If the request is new, begin processing it.
- If the operation is complete, return the previously stored result.
- If it is still in progress, handle the duplicate without starting another payment.
key: order-847key: order-847What did I learn?
Checking whether a key exists is not enough. The system must prevent two concurrent requests from starting the same operation, and it must coordinate with the payment provider to prevent a duplicate charge.
An API succeeding under normal conditions does not mean its design is correct.
For sensitive operations, I now ask: What happens if the request arrives twice, or if the connection fails halfway through?
Good engineering is not only about performing an operation. It is also about handling repetition and failure safely.
Conclusion
Never assume a request will arrive only once. Design the system to handle repetition safely.