What x402 actually is

x402 is an open protocol that turns HTTP's 402 Payment Required status code into a working payment flow. A server quotes a price in a machine-readable offer, the client pays by attaching a signed stablecoin authorization to its retry, and the server settles the payment and returns the content, all inside the same HTTP exchange. No account signup, no API key exchange, no checkout page. The whole thing takes two requests and settles in a few hundred milliseconds.

That one-paragraph version hides a 28-year backstory and a graveyard of failed predecessors, and you cannot really understand why x402 works without understanding why everything before it did not.

A status code reserved since 1997

Payment was in HTTP's design from the very beginning. Tim Berners-Lee's original status code notes describe a 402 PaymentRequired response whose parameter would specify "charging schemes acceptable", to be answered by the client retrying with a ChargeTo header. The header was never standardized. When HTTP/1.0 was written down as RFC 1945 in 1996, 402 was dropped entirely. RFC 2068, the first HTTP/1.1 spec in January 1997, brought the code back with a single sentence: "This code is reserved for future use."

That sentence survived unchanged through every revision since: RFC 2616 (1999), RFC 7231 (2014), and RFC 9110 (2022), the current Internet Standard for HTTP semantics. For nearly three decades, 402 was a registered status code with a name, a number, and no defined behavior. Servers could legally emit it, and some APIs did, informally, for quota and billing errors. But no client could programmatically act on a 402, because nothing defined what acting on it meant.

This turns out to be the useful part. Because the IETF never attached semantics to 402, the code was unclaimed territory: a layered protocol could define the request and response contract without conflicting with anything. That is exactly the gap x402 occupies. It is worth being precise here: x402 is an application-layer convention on top of an intentionally empty status code, not an IETF standard. So was L402 before it, and a client handling 402s in the wild may still encounter both.

Why every previous micropayments wave failed

402 was reserved during the first micropayments boom, when digital cash looked imminent. DigiCash, First Virtual, and CyberCash were all live or in trials by the mid-1990s; all were dead or bankrupt by about 2001. Three attempts are worth understanding in detail, because each failed for a different structural reason and x402 had to answer all three.

Millicent (DEC, 1995) targeted transactions "costing less than a cent" using vendor-specific scrip validated locally, with brokers as intermediaries. Technically clever, commercially dead: every merchant needed its own scrip, every buyer needed a broker relationship, and neither side would show up before the other did. Proprietary money creates a two-sided cold-start problem, and Millicent, DigiCash, and CyberCash all died on it.

The W3C micropayment markup (1999) standardized how to embed price, currency, and payment-system information in a web page so that competing wallet plugins could interoperate. It was parked as a Working Draft "to await significant implementation experience" that never arrived, because the wallets never shipped at scale and browsers never implemented payments natively. Note the shape of this era: payment metadata lived in page markup for human browsing. 402 sat unused even at the height of micropayment enthusiasm.

L402 (Lightning Labs, 2019) finally used the status code itself: the server replies 402 with a macaroon credential and a Bitcoin Lightning invoice in a WWW-Authenticate header, the client pays the invoice and retries with the payment preimage as proof. It works, and it is still alive, but adoption stayed niche. It requires Lightning channels and liquidity, settles in a volatile asset, and, like everything before it, was aimed at human buyers.

The human buyer is the deepest problem, and it was diagnosed before any of these systems failed. Nick Szabo's 1999 argument about mental transaction costs holds that the binding constraint on tiny payments is cognitive, not technical: deciding whether something is worth a cent costs more than the cent. Clay Shirky sharpened it in 2000: there is no no-brainer transaction, because any payment large enough to matter to the seller is large enough to force the buyer to think. That is why humans converge on subscriptions and advertising, which aggregate the purchase decision away. No protocol design fixes this, because the flaw is in the buyer.

So the failure had three layers: no settlement rail (card networks charge tens of cents in fixed fees, and inventing your own money creates the cold-start problem), no standard contract a client could act on, and a buyer for whom per-purchase decisions are inherently too expensive.

What changed: machines on the demand side

An AI agent with a wallet and a budget policy has zero per-decision cognitive cost. It can evaluate "is this data worth $0.004 for this task" thousands of times a day without fatigue, which makes it the first customer segment that micropayments ever actually fit. Szabo's and Shirky's objections were about human minds, and they simply do not apply.

The inverse also matters: agents cannot complete the checkout flows the web built for humans. Card forms, CAPTCHAs, and 3-D Secure are designed to stop non-humans. An agent that wants to buy a single API response today has to be pre-provisioned with an account and an API key for every service it might ever touch, which does not scale past a handful of vendors. Pay-per-request over plain HTTP is the natural interface for a machine buyer.

There is a motivated sell side for the first time too. AI crawling broke the ads-for-content bargain, and publishers want an alternative to blocking. Cloudflare launched pay per crawl in July 2025 on exactly this premise, and by September 2025 reported sending over a billion HTTP 402 responses per day to bots. Past micropayment waves had no seller pressure at all; this one started with it.

What changed: stablecoins on the supply side

The 1990s systems had to invent both the protocol and the money. x402 only had to invent the protocol, because the settlement rail now exists: USDC on low-fee, fast-finality chains. Coinbase's launch benchmark was settlement on Base in roughly 200 milliseconds with sub-cent fees, which makes a $0.004 sale economically sane in a way it never was on card rails with their tens-of-cents fixed costs.

The mechanism that makes this practical is EIP-3009, a function on the USDC token contract called transferWithAuthorization. The payer does not send a blockchain transaction. The payer signs a typed message authorizing the transfer of an exact amount to exactly one recipient, valid only inside a time window, usable exactly once (a random 32-byte nonce is burned on-chain when used). Anyone can submit that signature to the chain and pay the gas for doing so, but nobody can alter the amount or the destination, because both are inside the signed message. The result: the payer needs USDC but never needs the chain's gas token, and never exposes a private key to the seller.

How a payment actually happens

The flow is four steps. You can watch step one live right now against this server:

curl -i https://web-production-095eb.up.railway.app/r/eu-rates/today

1. The offer. The server replies 402 Payment Required carrying an accepts array of payment options. Each entry names a scheme (how to pay, such as exact), a network (which chain), an amount in atomic token units (USDC has 6 decimals, so "4000" means $0.004), the asset contract address, and the payTo recipient. This is the machine-readable price tag that 402 never had.

2. The signed payment header. The client picks one entry, signs an EIP-3009 authorization for it, and retries the same request with the signature in a payment header (X-PAYMENT in protocol v1, PAYMENT-SIGNATURE in v2). The header value is standard base64 of a JSON payload containing the signature and the authorization fields: from, to, value, time window, nonce.

3. Verify and settle. The server checks the payment before doing the work: does the signature recover to the claimed payer, does the amount match, is the recipient right, is the window valid, does the payer have the balance. Then it settles: the authorization is submitted on-chain and the money moves. Verification and settlement each map to one decision, so a server can do them locally or delegate them.

4. The receipt. The server returns 200 OK with the content, plus a settlement header (X-PAYMENT-RESPONSE or PAYMENT-RESPONSE) containing the transaction hash, network, and payer address, base64-encoded like everything else.

Facilitators are the delegation target in step three: third-party services exposing POST /verify and POST /settle. A resource server posts the payment payload and its requirements, and the facilitator checks balances and on-chain nonce state, simulates the transfer, broadcasts it, and pays the gas. This is why a publisher can accept on-chain payments with no chain infrastructure at all, not even a funded wallet: receiving USDC costs nothing, and the facilitator fronts the gas for settlement. A public no-auth facilitator runs at https://x402.org/facilitator for testnets, and Coinbase operates a mainnet one.

v1 and v2 in one minute

Two protocol generations are live. v1 (launched May 2025) puts the offer in the 402 response's JSON body, uses X-PAYMENT and X-PAYMENT-RESPONSE headers, and human-readable network names like base-sepolia. v2 (released December 2025, after v1 had processed over 100 million payments in six months) moves everything into headers (PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE), switches to CAIP-2 network identifiers like eip155:8453, restructures the payloads, and adds a formal extensions framework including discovery. It also tightens semantics: v1 accepted any authorization value at or above the required amount, v2 requires an exact match. The reference SDKs check v2 headers first and fall back to v1, and a compliant new server is expected to speak v2 while accepting v1.

Who runs it

Coinbase open-sourced x402 in May 2025, with AWS, Anthropic, Circle, and NEAR as launch collaborators. Google's Agent Payments Protocol announcement in September 2025 shipped a production x402 extension for agent-to-agent payments. Coinbase and Cloudflare announced an independent foundation the same month, and in April 2026 the x402 Foundation was formalized as a Series of LF Projects, LLC under the Linux Foundation umbrella, with 22 launch members including Cloudflare, Google, Visa, Mastercard, AWS, Stripe, Shopify, Circle, and the Solana Foundation. The canonical spec repository is github.com/x402-foundation/x402; the original coinbase/x402 is now a development fork. The protocol is Apache-2.0 and chain-agnostic.

Two honest caveats. Volume figures are self-reported by the project and skew toward high-frequency, low-value machine traffic. And 402 itself remains "reserved for future use" in RFC 9110; x402 has won the deployment race for the code, not a standards ruling.

How Tollgate implements it

Tollgate speaks both live generations on every paid URL. An unpaid machine request to /r/:slug/path gets a single 402 response carrying the v1 JSON offer body and the v2 PAYMENT-REQUIRED header at the same time, so both client generations can pay from one response. The spec allows this: v2 declares response bodies a server implementation concern, and the dual response is a strict superset of v1. You can decode the v2 header yourself:

curl -si https://web-production-095eb.up.railway.app/r/eu-rates/today \
  | grep -i '^payment-required:' | cut -d' ' -f2 | tr -d '\r' | base64 -d | jq

Every offer contains exactly two accepts entries, one per scheme:

Paying with the custodial scheme is one header:

PAYMENT=$(printf '{"x402Version":1,"scheme":"tollgate-credit","network":"tollgate","payload":{"apiKey":"tg_sk_..."}}' | base64)
curl -i -H "X-PAYMENT: $PAYMENT" https://web-production-095eb.up.railway.app/r/eu-rates/today

The reply arrives in whichever protocol version you paid with: an X-PAYMENT-RESPONSE header with v1 network names for v1 payers, a PAYMENT-RESPONSE header with CAIP-2 identifiers for v2 payers, plus an x402-receipt header on every successful purchase. If both payment headers are present, the v2 header wins, matching the reference SDK lookup order. One deliberate product rule sits on top of all of this: a browser request without a payment header gets a free HTML preview page. Humans still browse free; only machines pay.

To poke at it locally:

npm run dev        # http://localhost:3402
curl -i http://localhost:3402/r/eu-rates/today

From here: sell something in 5 minutes, give an agent a wallet, or go live with real USDC.