Duplicate Prevention

Overview

Duplicate Prevention begins at request intake. Clients should send a unique idempotency key for operations that can be retried after timeout. Stripe’s idempotency model stores the first result for a key and returns the same result to later matching requests.

Server-side controls are still required. Unique database constraints can protect order and provider identifiers, while atomic writes ensure that state change and side-effect scheduling occur together. A client key cannot protect against internal queue replay or a manually repeated operation.

Event consumers use Duplicate Suppression and processed-event records to avoid applying the same webhook or message twice. Financial workflows should also verify the current state so an already captured, refunded, or posted transaction cannot repeat an incompatible action.

Prevention differs from Duplicate Detection . Detection finds suspicious repeats, including cases that need review. Prevention enforces deterministic controls before value or ledger state changes.

No single control covers every failure mode. Systems need end-to-end reconciliation that compares provider transactions, internal records, ledger entries, and customer outcomes. A duplicate incident should lead to root-cause analysis and stronger control at the layer where the repeated effect occurred.

The protected business identity should be chosen before implementation. An idempotency key tied only to an HTTP request may not stop the same order from being charged through a second endpoint or operator tool. Systems should define canonical operation IDs for charge, payout, refund, capture, and posting actions, then enforce uniqueness wherever those actions can originate.

Recovery tools must follow the same uniqueness rules as production APIs. Emergency scripts that bypass idempotency can recreate the exact duplicate problem during an incident.