How idempotency stops double payments

You tap "Pay." The screen freezes. You tap again. Did you just pay twice? This is the problem idempotency helps solve, and it is why a well-built payment system can receive the same request twice and still charge you once.

What idempotent means

An operation is idempotent when repeating it has the same effect as doing it once. An elevator button is a good picture of it: press it five times and you still get one elevator. Reading a record is naturally idempotent. Charging a card is not, unless the system is designed to make it so.

How it works for a payment

1. The app gives the payment attempt a unique idempotency key, a value that stands for this one attempt.
2. The server processes the payment and records the result against that key.
3. If the app retries with the same key, the server recognizes it and returns the previous result instead of charging again.

A genuinely new payment gets a new key, so buying the same thing again on purpose still works.

Why retries happen at all

Networks drop replies, and apps retry. A request can succeed even when its response never reaches your phone. From the phone's side, a lost reply looks just like a failed payment, so it tries again. Without protection, every retry looks like a new payment, and retrying could create duplicate payments, orders or bookings.

Idempotency makes retries safer: repeat the request without repeating the action.

Why it matters

Retries are how apps cope with unreliable connections, and unreliable connections are a normal part of using a phone. Idempotency is what makes retrying safe, so an app can keep trying until it gets an answer without risking a double charge. The same idea protects any action that should happen exactly once, like placing an order or booking a seat.