Idempotency Conflict

Overview

Context and purpose

This is not an ordinary duplicate: a legitimate retry repeats the same logical request. Rather than returning the earlier result for a different instruction, it rejects the request with a conflict that tells the client to investigate or use a new key. The service retrieves the stored request fingerprint and compares it with the new payload, endpoint, account, and operation scope. The comparison policy should define which fields are material, how payloads are canonicalized, how keys are scoped, and what response is returned. These records support Payment Retry and let an operator reproduce the result from authoritative evidence rather than relying on a dashboard snapshot or a provider’s latest status alone. Idempotency Conflict should remain distinct from Payment Retry and Duplicate Request , because each can represent a different stage, record, control, or financial outcome.

How it works

A conflict occurs if a key already used for one operation is reused with materially different input. Instead of accepting the changed instruction, the server should identify the mismatch so a second financial operation is not disguised as a retry.

Practical checks and failure points

Specify canonical request fingerprints, account scope and error behavior. Never log secret parameters or use the same key across unrelated actions.

Related concepts

Idempotency Window · Duplicate Callback

Further reading

• docs.stripe.com official reference