The most frightening bug in commerce isn't a payment that fails. It's a payment that succeeds twice.
Networks are unreliable, so clients retry. A customer taps "Pay," the response gets lost on the way back, the app tries again — and now you've charged them twice for one order. The naive fix is to hope it doesn't happen. It happens.
Imagine instead that every payment attempt carried a unique idempotency key, and the server promised: the first time I see this key I do the work; every time after, I return the same result without doing it again. Suddenly a retry is safe. The client can fire the same request ten times over a flaky connection and the customer is charged exactly once.
That guarantee sat at the center of the checkout I built for Saturdays, a marketplace taking real orders through two payment gateways. The same idempotency key rides along the whole path, so a retried tap can never become a double charge — the reliability of the ordering-to-payment flow was the entire engineering priority.
Idempotency isn't a payments trick; it's how you make any operation safe to repeat. The moment retries exist in your system — and they always do — it stops being optional.
More backend and systems write-ups → www.divyakush.com
Top comments (0)