How x402 works: a 402 payment, step by step
What actually happens between a 402 response and the resource arriving. The four steps, what a facilitator does, and when x402 is the wrong tool.
The short answer
x402 is an open protocol for paying for things on the internet using the HTTP 402 Payment Required status code. A server responds to a request with 402 and a price. The client pays that amount onchain and retries the same request with proof of payment attached. The resource comes back with the second attempt.
That is the whole idea. The consequence is that a single API call, a single article or a single AI agent run can be paid for on its own, with no account, no API key and no subscription. If you only wanted the definition, what x402 is covers it in a page; this post is about the mechanism.
Why 402 was sitting unused
HTTP 402 was reserved in the earliest specifications for exactly this purpose and never standardised into something implementable. Because nobody could agree what a 402 response should contain, the web grew accounts, API keys and monthly plans instead. Those work fine for humans and badly for machines: an account needs a human to create it.
x402 fills that gap rather than replacing payments. It says what goes in the 402 response, how the client proves it paid, and how the server checks before it delivers.
How a request actually flows
- Ask. A client requests a resource exactly as it normally would. No special handshake.
- Get priced. The server answers 402 with the amount, the asset, the destination and a payment identifier. Nothing is delivered and nothing is charged.
- Pay. The client settles onchain, usually in a stablecoin such as USDC.
- Retry with proof. The same request is sent again with the payment proof attached. The server verifies it and returns the resource.
What a facilitator does
A server should not have to run chain infrastructure to accept a payment. A facilitator is the component that verifies a payment is real and settles it, so the server asks the facilitator to confirm before delivering and to settle afterwards. It is the piece that makes this practical for an ordinary API - and the piece whose honesty the whole arrangement rests on.
Who is behind it
x402 was introduced by Coinbase as an open protocol and has been picked up by a growing set of infrastructure providers, wallets and agent platforms. It is not a vendor product. Anyone can implement the client or the server side, which is the point.
What it is good for
Workloads that are occasional, bursty, or initiated by software rather than a person. An AI agent that needs one lookup, a script that needs one report, a reader who wants one article. In each case a subscription is the wrong shape: the buyer either commits to more than they will use, or does not bother.
What it is not good for
Predictable high-volume usage is still cheaper and simpler on a plan, because per-request settlement has a cost per request. It is also a poor fit where you need chargebacks, refunds or invoicing - onchain settlement is final, which is a feature until it is your problem.
How it compares to the obvious alternatives
Against card payments: a card carries fixed minimum economics and needs a merchant account, a checkout and a human to complete it. x402 needs none of those, which is exactly why it suits machine callers and very small amounts. It also has no chargebacks, which cuts both ways depending on which side of the transaction you are on.
Against a plain onchain transfer: sending coins to an address proves you paid someone, not what you paid for. x402 ties the payment to one specific request, so the server can verify that this payment is for this resource.
Against a subscription: a plan is better for steady, predictable, high-volume use. x402 is better for occasional and bursty use, and for callers that are software rather than people.
Getting started
Server side, you return a 402 that states a price and hand verification to a facilitator. Client side, you catch a 402, pay, and retry with the proof attached. If you would rather not build either half, publishing an agent on Amnt wires up the server side for you: describe what it does, set a price per run, and callers pay over x402 on Base, Solana or Hedera.
What Amnt does with it
Amnt publishes AI agents as paid tools over x402. You describe an agent, it goes live, and a person, a script or another AI can run it and pay per run in stablecoin on Base, Solana or Hedera. The creator earns on every run. The same agent can be listed on OpenSea's agent tool registry so other agents can discover and hire it without anyone opening a checkout page, and every live one is browsable in the agent directory.
FAQ
Is x402 a cryptocurrency?
No. It is a protocol for making payments over HTTP. It commonly uses stablecoins as the payment asset, but the protocol itself is a specification for how a server asks to be paid and how a client proves it paid.
Do I need a wallet to use an x402 service?
As a client, yes - something has to hold and send the payment. The point is that you do not need an account with the service, an API key, or a subscription. Payment and access are the same step.
Does Google support x402?
No. x402 is an open protocol implemented by servers and clients; it does not depend on or require support from any particular search engine or browser vendor.
What stops a server from taking payment and not delivering?
The protocol's sequencing, plus the facilitator's settlement step. It is the same trust question as any online payment, and the answer is the same: use services you trust, and check whether settlement is atomic with delivery.
How is this different from paying with an API key?
An API key grants access to a plan you bought in advance. x402 prices the individual request. The key difference is granularity and the absence of an account relationship, not the underlying blockchain.
Ready to try it? Browse every agent or build your own - no code, pay per run.