x402 is a protocol for paying for web resources through HTTP. A server returns payment requirements with HTTP 402; a compatible client authorizes payment and retries with a payment payload.
For an AI agent, that can turn one paid API lookup into part of the task. The wallet still needs permission to spend, and the service still has to deliver the result.
HTTP 402 becomes a price offer
HTTP 402 is the Payment Required status code. x402 adds a defined payment exchange around it; ordinary browsers don't automatically become autonomous purchasers because a website returns that status.
In the current V2 flow, the server communicates requirements through PAYMENT-REQUIRED. The client responds with a payment payload in PAYMENT-SIGNATURE. The server reports the settlement outcome through PAYMENT-RESPONSE. The header names describe separate steps, not three payments. HTTP 402 and V2 headers.
Imagine a research agent buying one weather observation for a route-planning task. A fictional offer asks for $0.001 in USDC, names the seller's receiving address and specifies a supported network and an exact-payment scheme. The payment client needs to recognize those terms before it can proceed. This price is illustrative, not an actual service quote.
A price offer isn't permission to spend. The wallet or application policy should check that the amount, merchant and requested resource fit the task. A server can quote an unreasonable price just as a human seller can.
From an unpaid request to a paid response
The agent authorizes a payment, while the seller controls when it releases the resource.
Follow one paid request
The client requests the resource. The server responds with payment requirements. The client chooses a supported option and creates an authorization or payment payload for that option. It repeats the resource request with the payload attached.
The server checks the payment and handles settlement under the selected scheme and payment flow. Default authorization verifies before the resource handler and settles afterward; an upfront flow settles before the handler runs. Escrow-based flows introduce funded balances and later capture or redemption. An exact price alone doesn't tell you when computation starts relative to settlement. Scheme and payment-flow overview.
The separation is useful for understanding a failure. A rejected authorization means the service hasn't accepted the proposed payment. A broadcast transaction waiting for confirmation means the money may still move. A completed payment with a missing resource is a delivery problem.
An interface that merges those states into “payment failed” encourages expensive retries. The client should preserve the request identity and reconcile the previous attempt before authorizing another purchase. Software can repeat a mistaken checkout much faster than a human.
The facilitator handles payment plumbing
A facilitator can verify payment payloads, submit settlement transactions and report their status. A resource server can use a managed production provider, operate its own service or handle these functions itself. The public quickstart facilitator shouldn't be assumed to be the production route for every network. Facilitator documentation.
The selected facilitator affects the service's operating dependencies. The seller needs support for its network, token and payment scheme. It also needs a workable response when the provider is slow or unavailable.
Non-custodial verification doesn't make every part of the business independent. A provider can be unable to submit transactions without holding the customer's funds. An API gateway can stop delivering resources without controlling the wallet. These failures belong in different parts of the incident plan.
Before launching a paid endpoint, I would test the route with the production provider and the real contract configuration. A successful testnet payment establishes that the integration can work in that environment. It doesn't establish production liquidity, pricing or reliability.
The scheme changes when money moves
An exact payment specifies a defined amount. An up-to payment authorizes a ceiling for usage whose final cost can be lower. Batch settlement groups charges for later onchain redemption, while auth-capture supports an escrowed, refundable pattern. These are different choices for a seller charging per request or per unit of work. Payment schemes.
A fixed-price data lookup fits a different billing problem from generating an answer whose computing cost depends on output length. The latter needs a clear maximum and a measurable final charge. The buyer should know how the seller calculates that charge.
In the documented EVM batch pattern, the buyer funds escrow and signs cumulative vouchers. The seller can claim later and sweep proceeds through a separate settlement operation. That explains how deferred charges can remain collectible, while also adding funding and redemption rules to inspect. Batch-settlement mechanism.
This is why a million paid requests shouldn't automatically be described as a million blockchain transactions. The micropayment economics article follows the costs at each layer rather than using request count as a proxy for chain revenue.
An AI model isn't the payment signer
The model can decide that a resource is useful and pass a purchase request to a tool. A wallet service or signing component creates the authorized financial action. Those roles should be visible in the system design.
Giving the model a task instruction such as “spend sensibly” offers weaker protection than an enforced transaction limit. A stronger setup checks the merchant, currency, maximum amount and remaining budget before the signer approves the request.
There is also a difference between a single purchase and continuing authority. A payment for one resource shouldn't quietly grant a seller access to an unrestricted balance. Our agent-wallet article explains how custody and spending permissions shape that boundary.
The agent's identity is another separate question. A payment proves a financial action under the relevant mechanism. It doesn't prove the buyer is a unique, competent or honest AI agent. ERC-8004 concerns identification and trust signals around agents, rather than replacing the payment exchange.
Payment and useful delivery need receipts
The service should identify the resource and the pricing unit clearly. “One response” can mean a search result, a complete dataset or a page of records. Ambiguous billing makes comparison difficult for both humans and agents.
Signed offers and receipts can help bind a purchase to declared terms and a recorded outcome. They still don't prove that every fact in a delivered dataset is correct. A buyer needs a way to assess freshness, provenance and whether the response serves the task. Signed offers and receipts.
For expensive or variable work, define what counts as a billable success. An empty result might be a valid answer to a query, but that rule should be stated before purchase. The same applies to a failed computation or an unavailable upstream source.
The seller's distribution problem remains. Enabling x402 doesn't make an endpoint discoverable or worth paying for. Selling data to agents covers that side of the business.
What to inspect in an x402 demo
Look for a visible quote, a constrained authorization and a distinct settlement result. Ask the team to retry a request after a simulated timeout and show that the original purchase isn't charged twice. Then ask what happens if the payment succeeds but the response is lost.
The useful demo finishes the customer's task under those conditions. A transfer explorer screenshot proves much less. Software buying a resource needs a reliable commercial exchange around the transaction.
For an alternative protocol and merchant integration approach, read x402 vs MPP. The choice starts with the service's billing pattern and the payment methods its customers can use.
One timeout needs two separate answers
Suppose a seller accepted payment for a weather observation, but the client never received the response. The next step depends on two records: did the purchase settle, and was that observation delivered?
A settled purchase with a missing response needs a delivery-recovery path. An authorization rejected before acceptance needs an explanation of the payment failure. A payment whose outcome is still unknown needs reconciliation before another authorization.
The payment identifier can help connect a retry to the original purchase when the extension is implemented. The seller still needs a rule for returning or recovering the purchased resource. Payment-Identifier extension.