How Can Agents Avoid Paying Twice? Start with a Timeout

An agent requests $1 of data, but the payment API times out. If it immediately pays again, the first request may already have succeeded and only the response was lost. A second request may create a second payment.

This discusses general design. Payment APIs do not all have the same retry, idempotency or refund semantics. Follow the particular service’s documentation and test results.

flowchart TD A[Payment request times out] --> B[Mark status unknown] B --> C[Check order and payment records] C --> D{Is status clear?} D -->|Paid| E[Check data delivery] D -->|Not paid| F[Consider retry under service rules] D -->|Still unknown| G[Pause for human handling]

Separate the states

State	What it says	What it does not establish
Client timeout	Client did not receive a result in time	Server definitely did not execute
Payment success	Payment system met its success condition	Product or data was delivered
Delivery success	Provider response was received	Final financial settlement is complete
Duplicate request	The same or similar request arrived again	Every service automatically deduplicates

What is an idempotency key?

An idempotency key is a stable identifier for one business operation. When an API supports it, retries of the same operation after a network failure should reuse the key under that API’s rules. Stripe’s API documentation describes storing the first result, key retention and parameter comparison; those are Stripe-specific semantics, not universal rules.

A key is not a universal safeguard. Check its scope and lifetime, how the service handles the same key with different parameters, and whether an initial error can be retried. A new key usually indicates a new operation; deduplication cannot be assumed beyond the retention period.

Questions to check

What identifiers connect the task, order, payment request and delivery?
Which statuses can be queried, and what do payer and service provider each retain?
How are duplicate or late callbacks handled?
When status is unknown, are further payments paused and budget reserved?
When is human contact needed, and what refund and reconciliation paths exist?

On-chain and x402 implementations can have different credentials, transactions and retry mechanisms. Do not assume one card API’s idempotency semantics apply industry-wide.