An AI agent pays for an API call, tool execution, dataset, or digital product. Then the HTTP request times out, the service returns an error, or the merchant never receives the webhook that should start fulfillment.
The dangerous assumption is that a confirmed payment equals a completed job. It does not. Payment verification and settlement answer a money-movement question. Delivery answers a business-outcome question. A reliable implementation must track both, reconcile them after failures, and choose a remedy without charging the agent a second time by accident.
A Paid Request Has Two State Machines
Treat each paid request as two related but separate records.
The payment record may move through states such as:
not_startedauthorizedsubmittedsettledfailedunknown
The service record may move through a different sequence:
not_admittedadmittedrunningdeliveredfaileddisputed
The request is complete only when the payment state satisfies the merchant's acceptance rule and the service state contains an accepted delivery result. A facilitator response, transaction hash, or webhook can advance the payment record without advancing the service record.
This distinction is consistent with the x402 architecture: a facilitator can verify a payment payload and settle it, while the resource server still decides whether and how to fulfill the request. It is also the reason an API should expose a payment ID, request ID, and delivery status instead of returning only a transaction hash.
Classify the Mismatch Before Retrying
The first recovery decision is not “retry or refund?” It is “which state is known?”
Observed state | What it means | Next action |
|---|---|---|
Payment unknown, no delivery | The client or merchant cannot yet establish whether funds moved. | Reconcile the payment and order before creating another payment. |
Payment settled, service not admitted | Funds were accepted but the business job never entered a durable queue. | Create a fulfillment record, retry admission without charging again, or apply the refund rule. |
Payment settled, service failed | The merchant accepted payment but execution failed. | Retry the business job with the same idempotency key, issue a credit, or refund according to policy. |
Client timed out, delivery may exist | The response was lost, not necessarily the work. | Query the result by request ID before rerunning or repaying. |
Service returned an invalid result | Payment may be valid but the output did not meet the contract. | Preserve evidence, mark the result disputed, and route to a defined remedy. |
This table matters because a second payment is often the wrong response to an unknown state. A timeout at the client does not prove that settlement failed. Conversely, a successful transaction does not prove that the requested report, inference, or tool result was delivered.
API Timeouts Do Not Prove Payment Failure
Consider a paid market-data request. The agent signs the payment, the merchant verifies it, the service begins work, and the connection closes before the response arrives. The agent sees a timeout. If it immediately repeats the full x402 flow, it may pay twice or trigger the same job twice.
Use a reconciliation sequence instead:
Keep the original business request ID and payment identifier.
Query the merchant or facilitator for the payment state.
Query the service for the request's execution and delivery state.
If the job is running, wait or poll within a bounded deadline.
If the job completed, retrieve the result rather than starting a new job.
If the job never entered execution, apply the admission or refund policy.
For asynchronous services, a status endpoint is usually more reliable than trying to keep one HTTP connection open. The client should receive a durable job reference, not only a best-effort response body. A payment-aware API can then distinguish “result pending” from “payment failed” and “result permanently unavailable.”
Payment Verification Is Not Business Success
Verification proves that a payment payload meets declared requirements. It does not prove that a model produced a usable answer, a file conversion finished, or a data query returned a complete dataset.
The merchant should make admission and fulfillment explicit:
Admission: payment terms were accepted and the job was assigned a durable ID.
Execution: the worker performed the requested operation.
Validation: the result passed schema, completeness, and policy checks.
Delivery: the agent can retrieve the result through the agreed channel.
This is especially important for services that can fail after payment. A model request can exhaust a provider quota. An MCP tool can call an upstream system that is unavailable. A report generator can create an empty or corrupted artifact. Returning HTTP 200 with an error-shaped payload may be technically convenient, but it makes refund eligibility and agent behavior ambiguous.
Define the delivery contract before accepting payment. Specify what counts as a successful result, what is partial delivery, how long a job may remain pending, and which evidence the merchant will retain. The agent can then make a bounded decision instead of interpreting every network response as success.
Duplicate Requests Need One Idempotency Key
An x402 retry can be correct at the protocol layer and still be unsafe at the business layer. The same request may pass through a payment intent, a wallet action, a blockchain transfer, a queue, and a result store. If each layer invents its own identifier, a retry can look new at the next layer.
Use one stable business key across:
The key should be stored durably and checked before creating a new payment or starting a non-idempotent job. A replay should return the existing payment or job state. It should not silently create a second order.
The x402 ecosystem includes a Payment-Identifier extension for this concern, and the official documentation also discusses duplicate settlement risks for some network paths. That protocol-level protection is useful, but it does not replace application idempotency. A merchant can avoid duplicate settlement and still run the same paid job twice unless the execution store uses the same key.
AgentKit provides a concrete implementation pattern here. Its runtime supports an idempotency store, including a Redis-backed option for distributed deployments, and its documented payment flow accepts an idempotency key for payment creation. The practical rule is broader than any one SDK: never retry a high-risk write until the prior attempt has been reconciled.
A Missing Webhook Is an Observability Failure
A webhook can be delayed, rejected, duplicated, delivered out of order, or lost during a deployment. Treating it as the only source of truth turns a notification problem into a payment incident.
Use webhooks to wake up work, not to define reality. The handler should:
authenticate the sender where the deployment supports signed webhooks;
record the event ID and ignore a duplicate event;
tolerate events arriving out of order;
fetch the authoritative payment or order state;
update fulfillment only after the state transition is valid;
schedule reconciliation when delivery fails.
GOAT Flow's public overview describes both backend status polling and deployment-defined webhooks, and says the merchant must confirm payment from a trusted backend source before fulfillment. That is the right operational boundary: a missing webhook should trigger reconciliation, not a new payment request to the agent.
Refunds Need Eligibility Rules and an Evidence Trail
An AI agent payment refund is not one universal operation. The remedy depends on what happened after settlement.
Automatic refund or credit
Automatic handling is appropriate when eligibility is deterministic. Examples include a payment that settled but never produced an admission record within a defined window, an order that expired before work began, or a system-level failure with a known error code.
The remedy may be a new onchain transfer, an account credit, or a retry entitlement. Record the original payment, the reason, the remedy ID, and the resulting status. Do not describe the refund as a reversal of the original blockchain transaction unless the payment design explicitly provides that mechanism.
Manual review
Manual review is more appropriate when the service delivered a partial result, the output quality is subjective, the agent changed its request after payment, or the evidence is incomplete. A support or operations workflow should inspect the request, payment, execution logs, output, and delivery attempt before approving a refund or credit.
Dispute handling
Onchain settlement is not the same as a card-style chargeback process. The merchant needs a service-level dispute path: a status record, a response deadline, evidence retention, and a clear decision. A dispute should not automatically authorize an agent to repurchase, nor should a merchant silently keep funds when its own delivery contract was not met.
The safest policy is to publish the remedy conditions before payment. Agents can then budget for a bounded risk, and merchants can automate only the cases where the evidence is strong enough.
Proof of Delivery Makes the Outcome Auditable
Payment proof answers “did the transfer satisfy the payment requirement?” Proof of delivery answers “what did the agent receive?” Keep both.
A useful delivery receipt can include:
business request ID and payment ID;
merchant order or job ID;
payment and delivery timestamps;
final delivery status;
artifact, result, or retrieval reference;
response or artifact hash where content integrity matters;
schema-validation or completeness result;
refund, credit, retry, or dispute reference when the service failed.
For an asynchronous tool, the receipt may point to a result URL or object identifier rather than embedding the entire result. For a streaming API, it may include the final sequence number and a digest of the delivered range. The format is application-specific; the important point is that “settled” and “delivered” remain independently observable.
Recovery Requires Both Payment and Runtime State
GOAT Network is relevant here because its public AgentKit and GOAT Flow documentation expose operational surfaces on both sides of a payment. The payer-side x402 plugin includes actions to create a payment, submit EIP-712 authorization data, transfer tokens, check status, and cancel. The merchant-side plugin covers portal operations such as authentication, orders, balances, webhooks, and API keys.
GOAT Flow also documents payment statuses including created, authorized, settled, failed, and expired. Those states help an agent or merchant determine whether it should reconcile, wait, cancel, or move to a service remedy. They do not by themselves decide whether a business result was correct or whether a refund is owed.
The AgentKit runtime adds useful controls around that boundary: policy gates, idempotency checks, bounded retries, timeouts, output validation, metrics, and hooks. Its documented default to avoid retrying high-risk writes is particularly relevant after a timeout. A payment or execution write should be reconciled before a second attempt, even when a generic retry policy would normally retry transient errors.
The boundary remains important. Developers still need to define the delivery contract, persist fulfillment state, verify outputs, handle webhook recovery, reconcile balances, and implement refund or dispute policy for their service. GOAT can provide documented payment and runtime building blocks; it does not turn an application-specific delivery promise into a universal protocol guarantee.
A Recovery Runbook for Developers
Use this sequence when an agent reports that it paid but received no usable service:
Freeze automatic repurchase. Do not create a second payment while the first payment state is unknown.
Correlate the incident. Locate the business request ID, payment ID, order ID, transaction reference, and trace ID.
Reconcile payment state. Check the authoritative merchant or facilitator status, not only the client timeout or webhook log.
Reconcile execution state. Check whether the job was admitted, running, delivered, failed, or disputed.
Recover an existing result. If delivery completed, return the stored result or a retrieval reference.
Retry only the missing stage. Retry execution without repaying when payment is settled and the job is safely idempotent.
Apply the remedy policy. Issue a retry entitlement, credit, automatic refund, or manual review according to recorded evidence.
Close the audit trail. Store the final payment, delivery, remedy, and notification states so a later dispute does not require reconstructing the incident from logs.
This runbook prevents two opposite mistakes: charging again when the first payment succeeded, and declaring success when money moved but the service did not deliver.
FAQ
What should happen if an AI agent pays but the API fails?
The agent should stop automatic repurchase, reconcile the payment state, and query the service by the original request or idempotency key. If payment settled and the job never completed, the merchant should retry fulfillment or apply its documented refund, credit, or dispute policy.
Should an agent retry after an x402 timeout?
Not the entire payment flow by default. A timeout means the response is unknown. Query payment and delivery status first. If the original operation is not complete, retry only the missing stage with the same idempotency key and a bounded attempt count.
Can x402 payments be refunded automatically?
x402 does not make every settled payment reversible like a card chargeback. A merchant can implement automatic refunds, credits, or retry entitlements for deterministic failure cases, but the policy, evidence, and refund transaction are application and deployment responsibilities.
What is x402 idempotency used for?
It helps associate repeated attempts with the same payment or request rather than treating every retry as a new charge. It should be extended through the application layer so payment intent, execution, and delivery records share one durable business key.
Does payment verification prove that the service was delivered?
No. Verification establishes that the payment payload satisfies the declared payment requirements. Delivery still requires a business execution record, a valid output, and a way for the agent to retrieve or accept the result.
How can GOAT AgentKit help with a failed paid request?
Its documented payer and merchant actions expose payment creation, authorization, status, cancellation, orders, webhooks, and other operational surfaces. Its runtime also provides policy checks, idempotency, retry and timeout controls, output validation, metrics, and hooks. Developers still need to implement service-specific delivery and refund rules.
Make Delivery a First-Class Payment Outcome
An AI agent pays successfully only solves the money-movement part of a machine-to-machine transaction. The useful outcome is a paid request that produces an accepted, retrievable service result exactly once.
Model payment and delivery separately. Reconcile before retrying. Bind every stage to one idempotency key. Keep webhooks subordinate to authoritative state. Define proof of delivery and refund eligibility before the first agent request reaches production. That is how x402 payment failure becomes a recoverable operational state instead of an unexplained duplicate charge.
