x402, Explained: The HTTP Status Code That Waited 30 Years for Stablecoins

The short answer: 402 Payment Required has sat in the HTTP spec since the 1990s, reserved for a future where the web had native money — a future that never shipped, so the code never fired. x402 is that future arriving: a server answers a request with 402 plus a machine-readable price; the client retries with a signed stablecoin payment attached in a header; the server verifies, settles on-chain, and returns the resource. No accounts, no API keys to provision, no card forms — a paywall any human or AI agent can clear in one round-trip. Here's how the handshake works, where it makes money appear that didn't exist before, and how to be on the receiving end. (Which is the good end — sandbox here.)

Thirty years of a missing primitive

HTTP shipped with status codes for "moved", "forbidden", "not found" — and 402 Payment Required, reserved because its authors could see that the web would need to charge for things at the protocol level. What they couldn't supply was the money: cards need accounts, forms, PCI ceremony, humans. So the web routed around the missing primitive with subscriptions, ad models, and API-key billing — all of them workarounds for "I just want to charge three cents for this request."

Two things changed. Stablecoins made digital dollars that settle in seconds for fractions of a cent — the first money that fits inside a web request's economics. And AI agents became buyers who can't fill card forms at all. x402 (introduced by Coinbase, open for anyone to implement) is the thin protocol that connects the dormant status code to the money that finally suits it.

The handshake, step by step

1. 1Client requests a paid resource — GET /api/report/today — like any request.
2. 2Server answers 402 with a machine-readable offer: price, accepted asset (typically USDC), network, and where to pay. Conceptually:

{
  "accepts": [{
    "scheme": "exact",
    "network": "base",
    "maxAmountRequired": "30000",
    "asset": "USDC",
    "payTo": "0xMERCHANT...",
    "resource": "/api/report/today"
  }]
}

1. 1Client pays and retries — same request, now carrying an X-PAYMENT header with a signed payment authorization matching the offer.
2. 2Server verifies and settles — checks the signature and amount, settles the transfer on-chain, and responds 200 with the resource. One round-trip of latency added; on fast chains, settlement confirms in about a second.

The elegance is what's absent: no account creation, no key provisioning, no invoice, no session. Payment becomes a property of the request itself — which is why the same paywall serves a human's wallet tool and an autonomous agent's budget identically.

What per-request pricing actually unlocks

• APIs without key ceremony. Today's API monetization means signup, tiers, quotas, dunning. x402 collapses it: any caller with stablecoins is a customer on request one. Keep tiers for your committed users; let the long tail pay per call.
• Content priced honestly. "Subscribe for $9/month" loses every reader who wanted one article. A ten-cent unlock was economically impossible on card rails and is trivial here.
• Agent-consumable everything. Data, compute, inference, scraping access — machine buyers with machine budgets can only buy what's machine-payable. x402 is the shape of machine-payable.
• Crawler paywalls with dignity. Instead of blocking bots or being strip-mined free, resources can answer automated demand with a price. Some of the web's oldest fights dissolve into commerce.

The honest boundaries

• It's young. The spec is real and implementations are live, but tooling is developer-shaped and conventions are still settling. Early-mover territory, with what that means both ways.
• It's for machine-sized purchases. Human consumer checkout has better answers (hosted checkout, QR, exchange transfers); x402 shines where requests are the product.
• Finality is final. Per-request payments settle irreversibly — the right property for delivered resources, and a reason to price requests, not promises.

Plugging in as a merchant

The receiving end needs what any crypto merchant needs — a wallet you control and settlement rails — plus a 402-speaking layer in front of the priced resource. The practical path:

1. 1Stand up stablecoin acceptance first — one API call creates payments with dedicated addresses; this serves your human customers today and is the settlement substrate for per-request billing.
2. 2Wrap priced endpoints with the 402 handshake — answer unpaid requests with the offer, verify X-PAYMENT retries, settle, serve. Facilitator services handle verification if you'd rather not.
3. 3Think in both durations: per-request for the long tail, vault subscriptions for committed usage — the machine customer's version of "pay as you go vs. plan", on the same rails.

FAQ

What is x402 in one sentence?

An open protocol that uses HTTP's 402 Payment Required status to let any web resource charge stablecoin payments per request — payable by humans and AI agents alike.

Who created x402?

Coinbase introduced it as an open standard; anyone can implement either side without permission.

What does an x402 payment cost?

The price is whatever the server asks; the rail overhead is a network fee measured in fractions of a cent — which is the entire point: three-cent purchases become rational.

Do I need x402 to accept crypto payments?

No — normal checkout covers human commerce. x402 matters when the request itself is the product: APIs, data, per-use content, agent traffic.

Is HTTP 402 finally official?

The status code has always been official — reserved and unused. x402 gives it a working payload convention; that's the "thirty years" joke in the title.

Can x402 handle subscriptions?

It's per-request by design. Recurring machine relationships fit better on vault subscriptions — automatic charges from a pre-funded, term-welded vault.

What chains does x402 work on?

Implementations center on fast, cheap chains where USDC settles in seconds — the same calculus as all payment traffic, sharpened by tiny ticket sizes.

How do refunds work for per-request payments?

They mostly shouldn't need to exist: deliver-on-pay makes the exchange atomic in practice. When warranted, a refund is a merchant-initiated transfer, same as any crypto payment.

The web reserved a slot for native payments before most of today's internet existed — and the money finally showed up. Open the sandbox, wire the settlement side, and the next 402 your server sends might be the first one in thirty years that gets paid.