Payment services often face double-charging issues when HTTP requests fail due to timeouts. Automated retry policies, if implemented without a robust architecture, can trigger multiple transactions for a single user action, leading to financial discrepancies.
Common attempts to solve this include disabling retries for POST requests or relying solely on the Idempotency-Key header. However, disabling retries leaves the system uncertain about transaction status, while relying on middleware like Redis can fail during system restarts or data loss.
The author argues that idempotency must be treated as a fundamental contract between all parties involved in the payment pipeline. This contract should persist from the initial client request through to the general ledger and final clearing files.
Retry mechanisms are merely tactical tools that function correctly only when a comprehensive idempotency contract is already in place. Without such a contract, automated retries do not improve system reliability and may accelerate failure.
