What is x402?

x402 is an open payment standard that lets a server charge for a resource directly over HTTP, using the status code that was reserved for the purpose in 1997 and then left alone for nearly thirty years. A client asks for something. The server replies 402 Payment Required and says what it costs and how to pay. The client signs a payment and asks again. A facilitator checks the signature and settles it on-chain. The server hands over the resource. That is the whole protocol, and its significance is not the mechanism, which is simple, but the fact that a payment has finally become a packet of information inside an ordinary request rather than a detour through a checkout page.

The four parts

1. The 402 response. When a request arrives without payment, the server answers with status 402 and a PAYMENT-REQUIRED header carrying the requirements: the amount, the asset, the network, the address to pay, and how long the offer is good for. There is no account to create and no key to present. The price is the response.

2. The signed payment. The client, which for our purposes is an agent, reads the requirements, signs a payment authorization with a wallet it controls, and retries the same request with the signature in a PAYMENT-SIGNATURE header. The keys never leave the client. The server only ever sees a signature it can verify.

3. The facilitator. Verifying and settling on-chain payments is work a resource server should not have to do itself, so x402 defines a facilitator with two endpoints, /verify and /settle, that a server can call to confirm a payment is valid and then to execute it. Coinbase runs one; anyone can. The facilitator is what lets a server accept payments without holding a wallet or watching a chain.

4. Settlement. The common case is USDC on Base, with Solana also supported, and any ERC-20 or SPL token in principle. Settlement takes about a second. The buyer pays the network gas, which on Base is a fraction of a cent, and most facilitators charge nothing on top. That fee floor is the number that matters, because it is what makes a one-cent payment economic when a card network's fixed fee makes it absurd.

Why it fits agents and did not fit people

Micropayments were supposed to be how the internet worked. The people who designed the early web expected billions of small transactions for articles, songs, and API calls, and the 402 code was set aside for them. It never happened, and the reasons are well documented: people hate deciding whether each small thing is worth it, card networks charge a fixed fee that makes small things uneconomic, and flat subscriptions are simply more pleasant for a human to live with. So the internet ran on advertising for consumers and subscriptions for businesses, and 402 sat unused.

Agents reverse every one of those objections. They have no decision fatigue. They prefer metering, because metering lets them compare vendors per call and switch when one gets slow or expensive. They do not need a pleasant billing experience. And on a chain like Base the fixed fee is small enough that a one-cent payment carries almost no overhead. x402 is the protocol that arrived when the buyer the protocol was always waiting for finally existed. It is not a coincidence that it was designed with agents in mind: the reference flow in its own documentation is an agent parsing a 402, signing, and retrying, and the SDKs assume a programmatic wallet rather than a person with a browser.

What it does not do

x402 moves value. It does not tell the buyer whether the seller is any good, whether the price is fair, whether the resource will actually arrive, or what to do if it does not. It provides no identity for either party beyond a signature, no reputation, no dispute mechanism, and no limit on what an agent holding a funded key might be talked into paying. Those are not flaws in x402; they are outside its scope, in the same way that TCP does not care what you send over it. But they are the reason a rail is not a market, and an agent that pays x402 directly needs something else in front of its wallet that says how much it is allowed to spend.

Where you can see it working

Vaaya exposes its pay-per-call endpoints over x402. The listing is a machine-readable file at vaaya.ai/.well-known/x402, and any agent holding USDC on Base can pay those endpoints with no account and no key, exactly as described above. Behind the account, Vaaya also settles with its own providers on x402 when that is the rail they accept, alongside Stripe's Machine Payments Protocol and Tempo, so an agent drawing on a Vaaya key is paying over x402 without holding a wallet of its own and inside a policy that bounds every call. The step-by-step of both paths, direct and through a gateway, is in how x402 works for AI agents.

The protocol's own documentation is at docs.x402.org.

Questions

What is x402?

x402 is an open payment standard, Apache-2.0 licensed, that lets a server charge for an API or a page directly over HTTP. The server answers an unpaid request with 402 Payment Required and the price; the client signs a payment and retries; a facilitator verifies and settles it on-chain; the server returns the resource.

What does HTTP 402 mean?

402 Payment Required is a status code reserved in the HTTP specification since 1997 for exactly this purpose and left unused for nearly thirty years. x402 is the first widely adopted protocol to give it a concrete meaning: the response carries the payment requirements for the resource that was requested.

Does an agent need an account to use x402?

No. That is the point. The buyer needs a programmatic wallet holding a supported stablecoin, USDC on Base or Solana in the common case, and nothing else: no signup, no API key, no card. The buyer pays the gas, settlement takes about a second, and most facilitators charge no fee of their own.