AI PAYMENT THREAT · PAYMENT REPLAY ATTACKS
Enforce consume-once authority before payment submission
Retries are normal; a second charge for the same approved action is not.
Where the failure appears
Network retries, duplicated tool calls and malicious replay can attempt the same authorized purchase more than once. In-memory deduplication does not survive restarts or coordinate regions, while MandateShield redemption alone cannot guarantee provider-side deduplication.
Who needs the control
Agent developers, payment infrastructure teams and merchants operating distributed or retrying systems.
Execution-time response
- Assign a stable idempotency key to the intended payment attempt.
- Persist the key and exact-input recovery binding with the authority decision.
- Use an account-wide database uniqueness boundary for concurrent requests and key rotation.
- Return the stored result for an exact network retry; block conflicting or concurrent reuse.
- Use stable, distinct keys for reservation, consumption, permit redemption and reconciliation; require a fresh redemption before provider submission.
Relevant controls
What changes
One strict attempt produces one durable reservation, and an integrated gateway can consume it once before its separately idempotent provider call.
Reproduce the failure safely
Change a sample amount, seller, consent field or instruction and inspect the structured decision before integrating.
Test the threat free →