Why x402? The HTTP status code that finally woke up.
HTTP 402 Payment Required has been reserved in the HTTP spec since 1997 and largely ignored ever since. Then three things converged: stablecoins became real money, L2s made fees disappear, and AI agents started needing to pay for things without humans in the loop. x402 is the protocol that finally gives 402 a job.
A status code that waited 25 years for its moment
Every developer who has ever fought with REST has seen them: 200 OK, 404 Not Found, 401 Unauthorized, 500 Server Error. Buried in the middle of that list is a code almost nobody has actually used in production:
10.4.3 402 Payment Required
This code is reserved for future use.
— HTTP/1.1 specification, RFC 2068 (1997)
— restated in RFC 2616 (1999) and RFC 9110 (2022)402 Payment Required has been part of HTTP since RFC 2068 in 1997, carried forward unchanged through RFC 2616 (1999) and the current RFC 9110 (2022). In every version, the spec says the same thing: reserved for future use. Credit card rails were too slow, too fee-heavy, and required signup flows that machines couldn't complete. So 402 sat in the spec, decade after decade, doing nothing.
HTTP has had a Pay button reserved in its spec since 1997. It took stablecoins and AI agents to finally press it.
What changed
Three things matured at once: stablecoins became real money, L2s drove transaction fees to fractions of a cent, and AI agents started needing to pay for things without a human in the loop. Together they finally gave HTTP 402 a job.
1. Stablecoins became real money
USDC and similar dollar-pegged tokens cleared regulatory hurdles, integrated into Coinbase, Stripe, and major banks, and proved that on-chain dollars settle in seconds for fractions of a cent. For the first time, a server could ask a machine for $0.002 and actually get $0.002.
2. L2s made fees disappear
Layer 2 networks like Base brought transaction costs from dollars on Ethereum mainnet to fractions of a penny. A $0.002 USDC payment on Base costs roughly $0.0001 in gas. The economics of true micropayments — where a single API call can be a single payment — finally close.
3. AI agents needed to pay for things
Humans tolerate signup flows. Agents don't. An LLM running a shopping loop, a research task, or a coding agent cannot stop every five minutes to ask a human for an API key, to read a terms of service, or to enter a credit card. Agents need payment that's as machine-native as the HTTP they're already speaking. That's exactly what 402 was reserved for.
What x402 actually is
x402 is an open protocol — originally proposed by Coinbase — that gives HTTP 402 a concrete wire format. It's deliberately small. It says: "if a server wants to charge for a resource, here is exactly the shape of the 402 response, the payment payload, and the verification flow."
The whole protocol fits in a single round-trip. No accounts. No OAuth. No keys. Just a handshake.
How the handshake works
# 1. Agent asks for a resource. No auth, no key, no header.
POST /api/v1/read HTTP/1.1
Content-Type: application/json
{"url": "https://example.com/article"}
# 2. Server replies 402 with a machine-readable price tag.
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"x402Version": 1,
"accepts": [{
"scheme": "exact",
"network": "base",
"maxAmountRequired": "2000",
"payTo": "0x63AE...Fcddc",
"resource": "https://skim402.com/api/v1/read",
"asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"
}]
}
# 3. Agent signs an EIP-3009 transferWithAuthorization for $0.002 USDC
# and retries the same request with X-PAYMENT set.
POST /api/v1/read HTTP/1.1
X-PAYMENT: eyJ4NDAyVmVyc2lvbiI6MSwic2NoZW1lIjoiZXhhY3QiLCJuZXR3b3JrIjoi...
Content-Type: application/json
{"url": "https://example.com/article"}
# 4. Facilitator settles the USDC on-chain. Server returns the content.
HTTP/1.1 200 OK
Content-Type: application/json
{"markdown": "# Article Title\n...", "metadata": {...}}That's it. Four messages, no setup, no shared secrets. The agent's wallet signs an EIP-3009 transferWithAuthorization message — an ERC-20 native primitive that lets a third party submit a USDC transfer on your behalf with your signature. A facilitator service (Coinbase's CDP facilitator on mainnet, the public x402.org one on testnet) verifies the signature and settles the transfer. The server only has to ask the facilitator "did this payment clear?" before responding.
Why it matters
For API providers: a real pricing model for the agent era
Traditional API monetization assumes a human signs up, pastes a credit card, picks a plan, and integrates a key. Every step is a conversion funnel that bleeds users. With x402, your billing system is one line of middleware and your "free tier" is "the first 402." Every call that returns 200 is paid. Refunds, fraud, chargebacks, and rate-limit games all evaporate because settlement happened before the response went out.
For agent developers: instant access to anything
The mental model shifts from "find APIs, sign up, manage keys, track quotas" to "give your agent a wallet with $5 of USDC and let it go shopping." When an agent encounters a new x402 endpoint it has never seen before, it can use it within milliseconds — no human in the loop, no API key provisioning, no rate-limit negotiation. This is what "machine-native commerce" actually looks like.
For the open web: a third business model
For 25 years the web has had two real ways to make money: ads (which require eyeballs) and subscriptions (which require commitment). Micropayments were the perpetual "what if" of the early web. With x402, sub-cent payments per request finally work — which means publishers, indie API authors, data providers, and content creators can charge a fraction of a cent per piece of content without tracking, accounts, or ads. Whether the open web takes it up is a cultural question, not a technical one anymore.
x402 vs API keys, in one table
| Concern | API keys | x402 |
|---|---|---|
| Time to first call | Minutes to days (signup, plan, key issue) | One round trip |
| Agent-friendly | No — requires human signup | Yes — fully autonomous |
| Billing model | Monthly tiers, overage surprises | Per call, paid before response |
| Fraud / chargebacks | Provider absorbs risk | Settlement first, no chargebacks |
| Key rotation, leaks, theft | Constant operational headache | No long-lived secrets to leak |
| Expiry / forced rotation | Often capped at 90 days — silently 401s a running agent | Nothing expires — each call is a one-time signed payment |
| Spam / abuse | Rate limits, CAPTCHAs | Each call costs money — abuse self-prices |
API keys were the right answer in 2010. In 2026, an autonomous agent shouldn't have to fumble with a long-lived secret it can leak. Skim doesn't accept API keys at all — the wallet that pays is the account.
Common objections, briefly
"Crypto is too complicated for my users"
From the API consumer's side, an x402 client is one wrapped fetch call — no smart contracts to deploy, no wallet UIs to build. From the provider's side, it's one Express middleware. Your users don't need to know any of the on-chain mechanics, the same way they don't need to understand TLS handshakes to use HTTPS.