There's a version of this story that plays out at almost every fintech startup I've worked with: the team ships a payment API, it works in testing, it goes live. Then a user's connection drops mid-request. The mobile app retries. The backend processes it twice. Two charges hit the customer's account. And suddenly you're in an incident with your compliance team asking uncomfortable questions.
Idempotency is the only thing standing between you and that story. After 11 years building payment systems — including integrations with instant payment rails, card processors, and core banking platforms — I have a strong opinion: if your payment API doesn't implement idempotency from day one, you've already shipped a bug. You just haven't seen it detonate yet.
What Idempotency Actually Means
An idempotent operation produces the same result no matter how many times you apply it. In the context of a REST API: if the client sends the same request multiple times, the server executes it exactly once and returns the same response every time.
HTTP GET and DELETE are idempotent by definition. POST is not — unless you design it to be. Payment submission is POST. So you have to build idempotency yourself.
