A city parking-fine service accepts payment callbacks that platforms may retry when the first response is lost. The handler currently charges the card on every invocation. What design change prevents double billing under at-least-once delivery?

Under at-least-once delivery, a parking-fine payment callback can succeed on the processor side while the caller never receives the success response, so the platform legitimately retries with the same intent. Making the charge path idempotent—keyed by a client-supplied or derived idempotency token—ensures a repeated request returns the original charge outcome instead of applying a second card debit. That design matches how municipal billing must behave when networks drop mid-handshake: the business effect is once, even if the wire sees the message twice.

Raising HTTP timeouts does not remove retries; platforms still retry on timeouts, disconnects, and ambiguous failures, and longer waits only delay the duplicate. Collapsing payment and receipt email into one synchronous monolith call may reduce hop count, but it does nothing for duplicate invocations of the charge itself and reintroduces the coupling microservices were meant to avoid. Disabling all retries and forcing operators to re-submit by hand trades automated resilience for manual toil and still leaves a window where a human click double-charges if the first attempt already succeeded.

Exam caveat: idempotency protects against duplicate application of the same logical request; it is not a substitute for exactly-once messaging infrastructure, which most cloud-native stacks do not guarantee end to end. Operational check: after deploy, replay a successful payment callback with the same idempotency key in a non-production lane and confirm the handler returns the stored result with no second authorization on the payment provider.