You've seen this bug. Maybe you've shipped it. Client sends a payment request. Network hiccups. Client doesn't get a response, so it retries. Your handler runs twice. Two charges. One very angry customer. This isn't a race condition. It's not a bug in your database layer. It's a missing contract between the client and the server: idempotency . What idempotency actually means in HTTP An HTTP endpoint is idempotent if calling it multiple times with the same input produces the same result — and more importantly, the same effect . GET is idempotent by definition. DELETE usually is. POST /payments is not — unless you build it that way. The pattern Stripe, Adyen, and most serious payment APIs use is the Idempotency-Key header : the client generates a unique key (usually a UUID) and sends it with every request. The server caches the response and returns it on any subsequent request with the same key, without re-executing the handler. Simple idea. Surprisingly few Go libraries implement it correctly.…