$200 duplicate charges traced back to a 2-second client timeout: the provider completed the first payment after 3 seconds, the caller retried, and the second attempt became the only payment recorded internally.
Pidvolotska argues the root issue was treating a timeout as a failure instead of an unknown state, which makes retries dangerous in money-moving systems even if longer timeouts reduce how often duplicates occur.
Four assumptions then broke around the idempotency key itself: claiming the key raced under parallel requests, one key was reused for $200 and $500 requests, cached declines blocked valid retries, and an older provider offered no idempotency support.
The fixes were to claim keys with a UNIQUE insert before calling the provider, fingerprint only stable business fields, cache only safe-to-replay successes, and rely on provider status checks plus reconciliation where guarantees end.
Her broader conclusion is that idempotency keys are necessary but not sufficient: payment systems need exactly-once effects, fail-closed behavior when the key store is down, and a clear source of truth when records disagree.