Because nobody likes being charged twice

Summary

Payment workflows can produce duplicate charges when a customer retries after a connection drop while the backend is still retrying the original request. The post frames network timeouts, crashes, database locks, downstream errors, and user interruptions as normal distributed-systems failures that can leave payment state uncertain. It recommends generating a unique idempotency key for one specific action, sending it with the Stripe request, and reusing it on every retry; Stripe recognizes the key for 24 hours and returns the original response. It also recommends placing payment jobs in a queue such as Amazon SQS, where workers retry failures and route repeatedly failing messages to a dead-letter queue. Together, queues preserve work during temporary outages and idempotency makes retries safe, while careful key scope and timing avoid stale or cross-operation behavior.

Context

Payment requests can enter an uncertain state when connections drop, servers crash, databases lock, downstream APIs fail, users interrupt transactions, or payment gateways become temporarily unavailable. Retrying without idempotency can create duplicate charges, while failing to retry can lose the request.

Approach / What changed

Generate an idempotency key for one specific payment action and include the same key on the initial Stripe request and all retries. Enqueue payment requests, process them with background workers, retry failed messages after delays, and send messages that exceed the retry limit to a dead-letter queue. The example uses Amazon SQS and AWS Lambda.

Takeaways

• Stripe uses an idempotency key to return the original response for repeated requests instead of creating another charge; the source states that Stripe recognizes the key for 24 hours.
• Amazon SQS can return a message to the queue after a Lambda visibility timeout or processing error, retrying it up to a configured maximum before sending it to a dead-letter queue.
• Keys should be unique to one operation, generated close to execution, and preserved across retries; reusing or omitting them can cause stale responses or duplicate charges.

Related reading