A replay attack repeatedly submits a previously captured API request, risking duplicate operations and compromised data integrity. section 12.1.2 section 12.5
A retried order or transfer
If a consumer receives no response after POST /orders, it may retry and create a duplicate. For POST /transfers, a mobile user may retry after a technical error even though the server already processed the transfer. section 12.1.2 section 12.5.3
Prevent replay by combining request identity with business-aware duplicate checks:
- Require a consumer-generated unique identifier, typically an Idempotency-Key UUID; reject a repeated identifier with 409 Conflict. section 12.5.3
- Detect identical business data, such as amount, source, and destination, within a context-specific time window. section 12.5.3
- Allow an intentional repeat through an explicit Confirm-Duplicate: true header. section 12.5.3


