The history of HTTP 402

Every developer has seen HTTP 404. Most have dealt with 401 and 403. Almost no one has ever received a genuine 402. That is not because the status code was never defined — it was, in 1996, in the original HTTP/1.1 specification. It was never implemented because the infrastructure to support it did not exist. Thirty years later, AI agents are finally the reason it does.

Defined in 1996, reserved for future use

RFC 2068, the original HTTP/1.1 specification published in January 1997, defined status code 402 as "Payment Required." The description in the RFC was brief and deliberately open-ended: the code was "reserved for future use" and intended for situations where a micropayment scheme would be required to access a resource.

The authors of the HTTP specification understood that the web would eventually need a way to charge for content and services programmatically. They anticipated micropayments. They reserved a status code for the purpose. What they could not anticipate was that human users — not machines — would be the primary consumers of web resources for the next three decades, and that the payment infrastructure required to make 402 meaningful simply would not exist at the scale needed until blockchain technology matured.

Why it was never used

The 402 status code sat unused for a specific economic reason: micropayments don't work with card rails.

Credit card interchange fees run 1.5 to 3.5 percent of the transaction value, plus a fixed per-transaction fee typically around $0.30. For a $0.99 query, that fixed fee alone represents a 30% overhead. For a $0.10 query, it makes the transaction economically impossible. The only payment infrastructure available for web transactions was designed for purchases of meaningful size — not sub-dollar API calls.

Various micropayment schemes were proposed and attempted over the years. None achieved meaningful adoption. The problem was not technical imagination — it was economic infrastructure. Without a payment rail that could settle sub-dollar transactions with overhead measured in fractions of a cent, 402 had nowhere to go.

What blockchain made possible

High-throughput blockchain networks — particularly Solana — changed the economic calculus. Solana can process thousands of transactions per second with settlement costs of a fraction of a cent. USDC, a dollar-pegged stablecoin issued by Circle, provides a stable unit of account without the volatility of non-pegged cryptocurrencies.

The combination of fast, cheap settlement and a stable dollar-denominated asset is what 402 was always waiting for. A $0.99 query with $0.0001 in settlement cost is economically viable. A $0.10 query is viable. Even $0.01 is viable. The per-unit economics that card rails made impossible become trivial on Solana.

x402 implements it — thirty years later

In 2024, Coinbase published the x402 protocol specification — a concrete implementation of the HTTP 402 status code for machine-to-machine payments. x402 specifies exactly what the 402 response body should contain (price, currency, recipient wallet address), what the payment proof format should look like, and how the retry request should carry that proof.

Why agents are the answer 402 was waiting for

The 1996 specification authors imagined humans paying for content — a fee to read an article, a micro-charge to access a database. What they didn't anticipate was that the callers who would actually benefit from per-request payment infrastructure would not be humans at all.

AI agents are the natural counterparty for 402. They operate programmatically, so a payment challenge-response that would be invisible to a human user is trivial for an agent to handle. They pay per result, which aligns with the value they receive. They don't need accounts or subscriptions because they are stateless economic actors by design. They operate at scale, which is precisely where per-request micropayment infrastructure shines.