A mobile client times out after sending a payment request, then retries. The first request actually reached the provider, but the response was lost. Without a stable idempotency key, the retry can charge the customer twice.
The scenario
Design an idempotent payment endpoint that records intent before calling an external provider, safely replays completed results, and distinguishes an unknown outcome from a rejected payment.
The question
How long should keys be retained? What happens when two different payloads reuse one key, or a worker crashes between provider success and local persistence?
The official solution is not published yet.Think it through with the community first.
Community discussion
0 contributionsBe the first to share your reasoning.