Protocols · x402

What is x402, and what does it actually do?

x402 is an open protocol that revives the web’s dormant 402 status code so services can charge machines per request. The agent asks, the server names a price, the agent pays and asks again — all inside an ordinary web request.

What is it?

The web’s own standard saved room for this decades ago. HTTP status code 402, “Payment Required,” has been reserved for future use since the 1990s (RFC 9110, Section 15.5.3). x402 is that future use.

It is designed for instant, low-cost payments for digital services: paid APIs, agentic commerce, paywalled content. There is no account to create and no API key to manage — the payment rides inside the request itself. Stablecoin payments are the primary use case, but the specification is deliberately network- and token-agnostic: it supports EVM-compatible chains, Solana, and more, and is written to extend to traditional payment methods.

Who is behind it?

x402 was created by Coinbase. On 2026-04-02, Coinbase contributed the protocol to the Linux Foundation, which launched the x402 Foundation as its neutral steward (launch announcement).

The Foundation was initially developed by Coinbase, Cloudflare, and Stripe. It launched with initial intent and support expressed by companies across payments, cloud infrastructure, and commerce — the full list is in the launch announcement above. The specification and reference code are an open standard under Apache 2.0, in the Foundation’s repository.

How does a payment flow?

Take OTTO, our example agent — an invoicing agent that buys text extraction (OCR) at $0.01 per page. One purchase is one short conversation:

1. OTTO requests the OCR service over plain HTTP.
2. The server answers 402 Payment Required, listing what it accepts: price, network, token.
3. OTTO picks one of the offered options and signs a payment payload with its wallet.
4. OTTO repeats the request with the signed payment attached in a header.
5. The server verifies the payment — locally, or by handing it to a facilitator, which also settles it on the ledger.
6. The server returns the OCR result, plus a settlement response OTTO keeps as its receipt.

The settled payment is a public-ledger transaction. Anyone can look it up on-chain — including you, and including us.

Two things the flow does not contain: an account and an undo. There is no signup step — the payment itself is the credential. And there is no reversal step — the flow defines verify and settle, nothing more, so any dispute process must be built on top. The protocol is also trust-minimizing by rule: no payment scheme may let the facilitator or the server move funds beyond what the buyer signed.

Where does it stand today?

Live, by its own account: as of 2026-09-02, x402.org describes the protocol as production-ready. The repository publishes reference SDKs in TypeScript, Python, and Go, and payment schemes including exact (pay a stated price), upto (authorize a cap, settle actual usage), and batch-settlement (settle many small charges at once).

What we cannot show you yet: numbers. x402.org publishes its own usage figures, and they do not appear here — our bar is numbers you can recompute, and our verification engine is not yet live. When it is, we will measure the USDC-on-Base slice of x402 activity independently. The bar itself: how we verify.

The other three rails this site covers, at the same depth and on the same template: AP2 & UCP, Stripe machine payments, and Verifiable Intent & Agent Pay. Side by side, every cell cited: the comparison matrix.

Where are the primary sources?

• Read the x402 specification — the protocol repository: spec, flow, schemes, reference code, Apache 2.0.
• Read x402.org — the protocol’s own site: documentation, FAQ, integration guides.
• Read RFC 9110, Section 15.5.3 — the HTTP standard that reserves 402 “Payment Required.”
• Read the Linux Foundation announcement — the 2026-04-02 launch of the x402 Foundation.