Duplicate API Request

Overview

How it works

The final control should feed Duplicate Payment , preserve the original evidence, and document any correction, override, or manual action. Important failure modes include duplicate or out-of-order delivery, incompatible schemas, lost acknowledgements, unbounded retries, stale consumers, forged messages, and replay that creates a second financial action.

It should return the stored result or a deterministic conflict instead of executing the financial side effect again when the original operation already completed. Controls should retain the request payload hash, authentication context, idempotency key, first-seen time, response, expiration policy, and linked payment object. Retries must use the same key and materially identical parameters for the same logical operation. The contract should define identifiers, schema and version, authentication, ordering, idempotency, retry behavior, error handling, and the service responsible for authoritative state.

What matters in practice

Duplicate requests occur when clients retry after a timeout, a queue redelivers work or two workers submit the same operation. The risk depends on the endpoint: two status queries are usually harmless, while two refund instructions can move funds twice. Use a client-supplied idempotency key scoped to a specific operation and persist the first accepted result. The server should reject reuse of the key with different payloads. Clients must also handle the provider's key-retention window and perform status lookup when they cannot tell whether the original call succeeded.

Related glossary concepts

Duplicate Payment; Payment Retry