HTTP already had a place for money. Nobody could put money there.
x402 is not a new website and it is not a new coin. It is a way to use the long-reserved 402 Payment Required status so a server can charge for a single HTTP request, in stablecoins, without creating an account.
The original sin of the commercial web
The web is good at moving documents and terrible at moving small amounts of money. Credit cards have a floor around thirty cents plus a percent. Bank transfers take days. So publishers sold attention to advertisers, and APIs sold monthly keys to developers.
Agents fail that assumption. They arrive without cookies, they do not watch pre-rolls, and they may make ten thousand GETs in an hour, each worth a fraction of a cent. If you cannot charge them, they will scrape you.
HTTP 402 was reserved in the 1990s for exactly this. The missing piece was a rail that could settle a thousandth of a dollar in about the time it takes to fetch JSON. USDC on cheap L2s is that rail. x402 is the handshake that hangs the rail on an HTTP response.
The loop
Coinbase shipped the first implementation; the protocol is Apache-2.0 and now sits with the x402 Foundation. You need a client that can sign, a server that can quote, and a facilitator that can settle.
- GET01
Ask for the resource
An agent requests a brief the same way it requests any JSON API. No account, no API key, no OAuth dance.
- 40202
Read the invoice
If PAYMENT-SIGNATURE is missing, the desk answers Payment Required. The PAYMENT-REQUIRED header is a base64 JSON quote: price, asset, network, payTo.
- PAY03
Sign and retry
The client (wallet SDK, agent runtime, or this playground) signs a payload and retries the same URL with PAYMENT-SIGNATURE.
- 20004
Settle and read
The desk verifies, fetches the brief, then settles. PAYMENT-RESPONSE comes back with the body. Failed briefs are not charged.
Three headers
Version 2 of the spec keeps the bodies out of the URL. Everything payment-shaped is base64 JSON in a header.
- PAYMENT-REQUIRED
- Server to client, on a 402. Lists accepted schemes, CAIP-2 networks, atomic token amounts, the asset contract, and the payTo address.
- PAYMENT-SIGNATURE
- Client to server, on the retry. Proves the buyer authorized a transfer that matches one of the accepted quotes.
- PAYMENT-RESPONSE
- Server to client, after verify/settle. Success or failure, plus a transaction id the buyer can check.
Facilitators, schemes, discovery
A resource server should not have to run a chain indexer. A facilitator verifies the payload and, for the exact scheme, settles it.
exact means “pay this amount, then get the bytes.” upto is for metered work. Briefbar uses exact because a brief has a known cost before we fetch it.
What this instance actually settles
The 402, the headers, the retry, and the “do not charge on failure” rule are real. The money is not. A local demo facilitator issues HMAC-signed payloads so you can learn the protocol without a wallet.
That split is the point of Briefbar: understand the product and the rail before you couple them to mainnet.