How to Recover Failed Agent Payments

An agent buys a generated report. The seller starts the job, then the HTTP connection drops. The buyer sees a timeout and tries again.

Did the payment fail? Did the report finish? Should the seller charge again? A timeout answers none of those questions. It tells you that one participant stopped receiving information.

In this hypothetical purchase, the safe next step is to inspect the existing payment and job. Recovery should resume that purchase from evidence. Replaying the whole flow can create a second charge, a second report, or both.

Keep the purchase when the response disappears

Give the purchase a durable identity before paid work begins. Call our example purchase-17. Its accepted offer identifies the requested report and price. Payment attempts and execution attempts belong to that purchase, even when one of them needs replacing.

The buyer's retry should resolve to purchase-17 and the same requested operation. If the report is complete and the payment condition for delivery is satisfied, return the stored result. If the job is running, return its status or a supported way to resume delivery. If payment is unresolved, inspect that payment before inviting another one.

A new attempt identifier is useful for recording another attempt. It grants no permission to charge or execute. The purchase state and the buyer's accepted terms still govern those decisions.

This is the integration requirement a seller should ask to see demonstrated: disconnect after work starts, reconnect with the same purchase, and observe what happens. A reassuring retry label proves very little.

Classify the failure before choosing a retry

Failures need a stable reason and a permitted next action. An unaccepted offer that expires requires a new offer and fresh acceptance. A malformed input needs correction before paid execution. An insufficient-balance response needs evidence that the spending condition has changed, such as funds becoming available or the buyer selecting another supported method. Waiting alone gives the seller no such evidence.

A verification-service timeout leaves a different question open: was verification completed? A settlement timeout may leave an externally submitted payment unresolved. Neither should be flattened into a generic instruction to pay again.

Return enough information for software to act: the purchase reference, the unresolved operation, a stable failure reason, and whether the next step belongs to the buyer or to reconciliation. Avoid exposing sensitive internal diagnostics in that response.

One purchase, five recovery boundaries

Resume from the purchase state you can prove.

Stage	What is unresolved	Evidence to inspect	Safe next action
01Quote	The unaccepted offer expired or was replaced.	Quote ID, version, price, and expiry	Issue a new quote and require a new authorization.
02Authorize + verify	The current payment evidence does not satisfy the requirement.	Stable reason and payment-attempt ID	Ask for buyer action or corrected evidence before execution.
03Execute + deliver	Work may have run, but the result did not arrive.	Execution attempt, stored result, and payment/delivery state	Inspect execution and payment. Return the result only when the delivery payment condition is met; resume or restart work after resolving conflicting effects.
04Settle	A broadcast or external side effect has unknown finality.	Settlement reference, network, and current state	Reconcile the reference before another settlement attempt.
05Compensate	Payment completed but fulfillment did not meet policy.	Original transaction, delivery evidence, and remedy	Create a linked refund or agreed compensation. Cancellation applies before payment completion.

The stages in the figure are evidence boundaries. Their order depends on the payment method and selected flow. A settled payment and an undelivered report can coexist.

Give one worker ownership of execution

Two retries can arrive together. Checking for a stored report and then starting a job is unsafe if both workers see an empty result.

Require an atomic claim on the purchase's execution: one worker gains permission to start or resume the job, while competing requests observe the existing operation. A database uniqueness constraint or transactional claim can establish that local ownership. Persist the external job reference and completed result so later requests can recover them.

The harder gap comes when an external service creates the report and the worker crashes before recording success locally. A local lock cannot undo or prove that external action. Reconcile the existing job reference, or use the downstream service's supported idempotency mechanism, before starting another job. If the effect cannot be established safely, keep execution unresolved and send it to the defined reconciliation owner.

For a downloadable result, retain the report or a stable reference for the promised redelivery period. For an irreversible action, the seller needs a different recovery policy. The word “retry” cannot make either case safe by itself.

State what each idempotency key protects

RFC 9110 defines an idempotent method by its intended server effect. That HTTP property does not guarantee that a payment integration, job runner, and external provider collectively execute a purchase exactly once.

An application's idempotency key needs a stated scope, such as one buyer's report-generation operation under one purchase. Reusing that key with a different report input should be rejected. The integration must also say how long it retains the key and result, and what concurrent requests observe while execution is in progress.

Provider semantics matter too. Stripe's idempotency documentation distinguishes API versions. API v1 stores the first executed response for a key, including errors; API v2 can continue failed or partial work and return an updated result. Use the behavior of the API you actually call. A provider's retained response does not prove that your own fulfillment ran once.

For purchase-17, keep the purchase identity stable while recording distinct payment and job attempts beneath it. Create a new attempt only when the preceding attempt's state permits it. After retention expires, reconcile the purchase rather than silently treating an old retry as a new sale.

Reconcile a broadcast payment before another charge

The x402 v2 specification defines settlement_pending as non-terminal. A transaction was broadcast, but confirmation could not be established before a timeout or node failure. The response carries the transaction hash and network so the caller can check that transaction.

Suppose the report for purchase-17 is ready while settlement is pending. Preserve both facts. Query the existing settlement reference using the method's supported reconciliation path and apply the chosen delivery policy. Do not erase the ready report, report a definitive payment failure, or create another charge merely because the HTTP wait ended.

Bound retries with a deadline, backoff, and an escalation owner. Those limits control how long the system keeps trying; they do not transform an unknown payment into a failed one. Keep the unresolved reference available for later reconciliation.

Choose the remedy after establishing what happened

If the report was delivered under the accepted terms, return its existing receipt and result. If delivery failed but can still be completed safely, redeliver the purchased report. If payment completed and fulfillment cannot meet the agreed policy, record a refund or another agreed compensation against the original purchase.

Cancellation belongs before a payment reaches the state that requires a refund. Stripe's refund guidance illustrates that distinction for its payment lifecycle; another rail may expose different states and remedy operations. A completed transfer may require a separate return transfer rather than reversal of the original event.

Preserve the original outcome and add the remedy. Support should be able to identify the accepted offer, payment reference, execution result, and current recovery owner from the purchase reference, with access limited to the information each role needs.

For your first paid resource, choose the retry and remedy policy, then require the integration to demonstrate it at the uncertain boundaries. An Agent Paid. Now What? follows the wider commercial record. Recovery has a narrower job: establish what happened to this purchase before allowing the next effect.