How x402 works for AI agents

An agent pays with x402 in five steps, and only one of them involves the agent thinking. It requests the resource. The server refuses with a price. The agent signs a payment for that price and asks again. Someone verifies the signature and settles the money. The server hands over what was asked for. What follows is each step with the actual headers, then the part every tutorial leaves out, which is what stands between the agent's wallet and an agent that will pay any price it is shown, and finally the same purchase made through a gateway so you can see what changes.

The direct path

Step 1. The request. The agent calls the endpoint as if it were free.

GET /api/search?q=machine+payments HTTP/1.1
Host: api.example.com

Step 2. The 402. The server has no payment, so it answers with the status code and the requirements. The body is whatever the server likes; the header is the protocol.

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: {"scheme":"exact","network":"base","asset":"USDC","amount":"10000","payTo":"0x...","maxTimeoutSeconds":60}

The amount is in the asset's smallest unit, so the example is one cent of USDC. The agent now knows the price, the asset, the chain, and where the money goes, and has a minute to decide.

Step 3. The signed retry. The agent's wallet signs an authorization to transfer that amount to that address. The private key stays in the agent's environment. What travels is a signature.

GET /api/search?q=machine+payments HTTP/1.1
Host: api.example.com
PAYMENT-SIGNATURE: <base64 payment payload>

Step 4. Verification and settlement. The server does not want to watch a blockchain, so it forwards the payload to a facilitator, which exposes /verify to confirm the signature and requirements match and /settle to execute the transfer on-chain. On Base this takes about a second. The buyer pays the gas, which for a USDC transfer is a fraction of a cent, and most facilitators charge no fee of their own.

Step 5. The resource. The server returns the search results, usually with a header confirming settlement so the agent has a receipt it can keep.

Five steps, no account, no API key, no checkout. That is the protocol working exactly as intended, and it is why x402 is the rail agents were waiting for.

The part the tutorials skip

Step 3 has a hidden assumption: the agent decided the price was acceptable. Nothing in the protocol makes it decide that. A 402 says what a resource costs; it does not say whether the resource is worth it, whether the seller is who it claims, or whether the agent should be spending this much this often. An agent with a funded wallet and no policy will pay whatever the header says, and it will pay it to whatever address the header names, which is a design that lasts exactly until the first page the agent scrapes contains instructions.

So an agent paying x402 directly needs three things beyond the SDK. A wallet holding USDC and enough gas. A signer that does not expose the key. And a policy that decides, before step 3, whether to sign at all: a maximum per call, a maximum per period, a list of endpoints or categories it may pay, and a record of what it paid and what it refused. The wallet frameworks that target agents ship policy engines for this reason. The policy is not an optional extra on top of x402. It is the thing that turns a payment protocol into a spending decision.

The same purchase through a gateway

Now the other path. The agent holds no wallet. It holds a key to an account a person owns, and the key carries the policy: categories, a monthly limit, and the obligation to state a maximum cost on every call. The purchase looks like this from the agent's side:

{
  "service": "exa",
  "action": "search",
  "params": { "query": "machine payments", "numResults": 10 },
  "max_cost_cents": 5,
  "intent": "sources for a protocol comparison"
}

Behind that call, the gateway does steps 1 through 5 for the agent. It requests the resource, receives the 402 if the provider is an x402 endpoint, compares the price to the ceiling the agent stated and to the limits on the key, signs with its own wallet if everything passes, settles through the facilitator, and returns the resource to the agent with a receipt. If the price is above the ceiling, the gateway never signs; the agent gets a refusal with the reason and the actual price, and nothing moves. If the provider accepts a different rail, Stripe's Machine Payments Protocol or Tempo, the gateway pays on that instead, and the agent's side of the exchange is identical. If the call fails, nothing is billed.

The agent has made an x402 payment without holding a key, without holding gas, without knowing which chain was used, and inside a limit it could not have exceeded. The policy that was optional and self-built on the direct path is mandatory and enforced on this one.

Which path, and when

Pay x402 directly when the agent is itself an on-chain actor: it holds value for other reasons, it pays a single known endpoint repeatedly, or it is paying another agent rather than a service. The protocol is at its best here, and a gateway would only add a hop.

Pay through a gateway when the agent is an employee rather than a market participant: it will use many tools, its owner needs a limit that the agent cannot argue with, and nobody wants a private key with a balance living in a coding assistant's configuration. That is most agents, most of the time, and it is what Vaaya is. The account settles on x402, MPP, or Tempo as the provider requires; the agent sees a ceiling and a policy.

Vaaya's own x402 endpoints are listed at vaaya.ai/.well-known/x402 for agents on the direct path. The definition and history of the protocol are in what is x402, and the official documentation is at docs.x402.org.

Questions

How does an AI agent pay with x402?

It requests the resource, receives a 402 with the price and payment requirements in a PAYMENT-REQUIRED header, signs a payment authorization with its wallet, and retries with the signature in a PAYMENT-SIGNATURE header. A facilitator verifies and settles on-chain in about a second and the server returns the resource.

Does the agent need ETH for gas?

The buyer pays gas on-chain, so an agent paying x402 directly needs enough of the network's gas asset, or a wallet arrangement that covers it. On Base the gas for a USDC transfer is a fraction of a cent. An agent paying through a gateway needs nothing on-chain at all.

Can an agent use x402 without holding crypto?

Yes, through a gateway that holds the wallet and pays x402 endpoints on the agent's behalf. The agent holds a key with a spending policy instead of a private key with a balance, states a maximum cost on every call, and receives the resource and a receipt.