x402 for Paid APIs: The Payment Can Succeed While the Response Fails
How the x402 paid-API exchange works, why verification is not settlement, and which retry and reconciliation controls an operator must add.
x402 puts a payment challenge and proof into an HTTP request. Coinbase's documented flow separates verification, resource execution, settlement and response delivery. The gaps between them determine retries and reconciliation.
x402 lets a server quote a price for an HTTP resource and lets a client or agent retry with a signed payment. In Coinbase's documented flow, the facilitator verifies the proof, the server performs the work, the facilitator settles, and the server returns the resource. Verification, settlement and successful delivery are distinct states. Operators must define idempotency, retry, refund and reconciliation behavior for their own endpoint rather than assume the protocol supplies it universally.
The interesting x402 failure is not always “payment declined.” It is payment settled, response lost. The agent sees a timeout and may try again. The seller may already have been paid and may already have performed the work. Without a request-level recovery rule, both sides can disagree about what happened.
The documented exchange
Coinbase's x402 flow describes a client requesting a resource, a server quoting payment requirements, and the client retrying with a signed payment. In its CDP Facilitator example, the server asks the facilitator to verify the payload, performs the work, asks it to settle, and returns the resource with payment confirmation. x402 is useful for an agent purchasing an API call mid-task, but the exchange does not depend on the client being an agent.
| Boundary | What the implementation learns | What is still open |
|---|---|---|
| Price challenge | Asset, network, recipient and amount offered by the server | Whether the client can or will pay. |
| Signed retry | A payload was presented for that requirement | Whether it passes verification. |
| Verification | The facilitator accepts or rejects the payload for the requirements | Whether settlement succeeds. |
| Resource execution | The server has run the requested operation | Whether it will be paid and whether the client will receive the result. |
| Settlement | The facilitator reports the payment outcome | Whether the HTTP response reaches the client. |
| Response delivery | The client receives the resource or an error | Whether a retry represents a new purchase or recovery of the old one. |
That last column is an operator checklist, not a set of guarantees in x402. Coinbase's Facilitator page says its hosted service verifies signed payments, screens transactions, submits settlement onchain and reports the result. Its API exposes verification separately from settlement. Do not count a successful verify response as a collected payment.
Design for the failure between steps
| Failure | Buyer or seller symptom | Control to design and test |
|---|---|---|
| Verification rejects the payload | Client paid nothing usable for this request | Return a clear failure and avoid running the paid operation. |
| Work fails before settlement | No useful resource was produced | Define whether the payment is submitted, cancelled or retried; the answer depends on the chosen scheme and implementation. |
| Settlement fails after work | Seller performed work without confirmed receipt | Retain a correlation record and reconcile before treating it as paid. |
| Settlement succeeds; response is lost | Client times out while seller has a receipt | Offer a way to retrieve the prior result without silently charging for a second identical request. |
| Agent retries with a new payload | Two payment attempts may exist for one task | Detect duplicate intent and show which attempt paid for which resource. |
These are PaymentBrief's suggested controls. They are not claims that the protocol automatically supplies deduplication, refunds or replay behavior for every endpoint. Keep a seller-side operation ID, the priced resource and version, payload or transaction reference, facilitator verification and settlement results, and final delivery status together. Define the retry key and retention period in your own API contract. Test a timeout after settlement deliberately in a non-production environment; a happy-path response is not enough.
Scope and money boundaries
The x402 standard is described as network-agnostic, but a particular facilitator supports a particular set of assets, networks and schemes. Coinbase's current CDP page lists x402 v2 support for named EVM networks and Solana and describes different handling for exact, upto and batch-settlement. Check its live supported-schemes endpoint before integration; the documented network list can change. Do not infer that a feature present in the wider protocol works on every CDP network. Nor does accepting a stablecoin remove wallet funding, custody, screening, conversion or off-ramp questions. Coinbase describes screening and hosted settlement for its Facilitator; your organization still needs to determine who controls the receiving wallet and how value reaches its books or bank.
Before allowing an agent to purchase paid API calls, put a per-call and total budget around its signer, decide which counterparties and networks it may use, and reconcile its signed requests against settled payments and delivered resources. The agent payment-controls guide covers the delegation boundary; the agentic protocol map covers retail commerce and agent identity, which are different from paid API access.
Sources & methodology (3)
Coinbase's x402 documentation describes a paid HTTP resource and a client-server-facilitator flow with separate verification, resource execution, settlement and response steps
Checked:
The CDP Facilitator page lists x402 v2 networks and schemes, distinguishes verification from onchain settlement, and describes fee treatment for onchain transactions
Checked:
The verify endpoint accepts a payment payload and payment requirements and is separate from the settle endpoint
Checked:
Source types explained in our Methodology.
By Shaun Toh · Director, Digital Payments · Razer