Writing Idempotency Keys Before Processor Calls Prevents Double-Charge Bugs

A developer traced a double-charge bug to the order in which idempotency keys were written, not to retry timing or refunds. The original middleware called the payment processor first and only saved the idempotency key after a successful charge, leaving a gap if the process crashed in between. When a pod was killed after the processor accepted the charge but before the key was stored, a client retry found no record and triggered a second charge. The fix involved writing the key with a 'pending' status before contacting the processor, then updating it to 'complete' afterward, so any mid-flight retry could detect the in-progress state. This approach narrows the failure window to a single database update, though it adds a small number of extra writes per request.