HTTP 402 Payment Required

HTTP 402 is a status code in the HTTP specification that indicates a request cannot be fulfilled until the client provides payment. Unlike its neighbors in the 4xx family — 401 Unauthorized and 403 Forbidden — the 402 code was never given a standard implementation. It was reserved "for future use" in 1999, and that future took over two decades to arrive.

Origins: RFC 2616 and the 1999 Reservation

The HTTP/1.1 specification, published as RFC 2616 in June 1999, defined the full range of status codes that web servers could return to clients. Among them was 402 Payment Required, described in a single paragraph:

This code is reserved for future use.

The intent was clear. The architects of HTTP anticipated that the web would eventually need a native mechanism for servers to demand payment before serving a resource. The web was already commercial by 1999 — Amazon had been selling books online for four years, eBay was processing millions of auction transactions — but no standardized protocol existed for a server to say "pay me first" and for a client to respond with a payment in the same HTTP exchange.

The reservation was forward-looking, but the specification provided no headers, no payload format, and no negotiation mechanism. It was a placeholder, not a protocol.

Why It Was Never Implemented

The 402 code remained dormant because the payment infrastructure of the late 1990s and early 2000s could not support it. Several factors made implementation impractical.

No Client-Side Payment Capability

Web browsers had no built-in mechanism for authorizing payments. A server could return a 402 response, but no browser knew what to do with it. There was no equivalent of the WWW-Authenticate header (used by 401) that could negotiate a payment method between client and server.

Credit Cards Could Not Work Over HTTP Headers

The dominant online payment method — credit card entry — required form-based input, server-side processing through payment gateways, and PCI DSS compliance. None of this could be reduced to a header-based exchange. A credit card transaction involves sensitive data, multi-party settlement (issuing bank, acquiring bank, card network), and a fundamentally different trust model from what HTTP headers were designed to carry.

Micropayment Systems Failed

The 1990s saw several attempts to build digital micropayment systems that could have given 402 a purpose.

Each system required either proprietary client software, special hardware, or centralized intermediaries that undermined the open nature of HTTP. None achieved the network effects necessary to justify browser vendors building native support.

No Standard Payment Negotiation

Even if a payment mechanism had existed, HTTP lacked a standard way for the server to communicate what it accepted and for the client to respond with proof of payment. The 401/WWW-Authenticate pattern for authentication was well-defined, but no equivalent Payment-Required/Payment-Signature pattern was specified for payments.

The 25-Year Gap

The 402 status code was carried forward unchanged through successive HTTP specifications.

For a quarter century, the code sat in the specification while the web developed entirely different monetization models. Online commerce routed payments through checkout flows, shopping carts, and third-party processors. APIs monetized through API keys tied to billing accounts. Content monetized through advertising, subscriptions, and paywalls. None of these models used HTTP 402. None of them needed to.

The web did not lack payment — it lacked payment at the protocol level.

402 in Context: The 4xx Status Code Family

To understand what 402 was designed to express, it helps to see it alongside related client-error status codes.

The pattern is consistent: 401 means "identify yourself," 403 means "you are identified but not allowed," and 402 means "you are allowed but have not paid." Each code represents a different gate that a request must pass through. The 402 gate simply never had a mechanism to open it.

What Changed: Cryptocurrency and Programmable Money

Three developments in the 2010s and 2020s created the conditions that the 402 code's original designers anticipated but could not build for.

Client-Side Wallets

Cryptocurrency wallets — both browser extensions (MetaMask, Coinbase Wallet) and embedded agent wallets (Privy, Turnkey, CDP) — give clients the ability to sign payment authorizations locally. Unlike credit card numbers, a cryptographic signature can be included in an HTTP header without exposing sensitive data. The private key never leaves the client.

Stablecoins

Early cryptocurrencies like Bitcoin and Ether were too volatile for pricing API resources. A request priced at $0.01 in ETH might cost $0.008 or $0.013 by the time it settled. Stablecoins — particularly USDC and USDT, pegged to the U.S. dollar — solved this. A server can price a resource in USDC, and the client knows the exact dollar cost at the time of signing.

Programmable Settlement

EVM-compatible blockchains (Ethereum, Base, Arbitrum, Optimism) support smart contracts that can execute payment logic on-chain. Standards like EIP-3009 (transferWithAuthorization) allow a token transfer to be authorized by the payer's signature and executed by a third party — meaning the client signs, a facilitator submits the transaction, and the client never needs to hold native gas tokens or broadcast a transaction.

The x402 Protocol: HTTP 402 Realized

The x402 protocol is the first practical implementation of HTTP 402 as a machine-native payment standard. It defines the headers, payload formats, and negotiation flow that the original specification left unspecified.

The flow works as follows:

1. The client sends a standard HTTP request to a paid resource.
2. The server returns 402 Payment Required with a Payment-Required header containing the price, accepted token, network, and recipient address.
3. The client's wallet signs an EIP-3009 transferWithAuthorization for the specified amount.
4. The client resubmits the original request with the signed authorization in a Payment-Signature header.
5. A facilitator verifies the signature, confirms the client's token balance, and settles the transfer on-chain.
6. The server delivers the requested resource along with a Payment-Response header containing the settlement receipt.

The entire exchange happens over HTTP. No redirect to a checkout page. No API key lookup. No billing account. The payment is embedded in the request-response cycle, exactly as the 402 status code was originally envisioned.

Why Now: The Agent Economy

The timing of 402's revival is not accidental. The rise of autonomous AI agents — systems that browse the web, call APIs, and execute multi-step tasks without human intervention — has created urgent demand for machine-native payments.

An AI agent cannot fill out a credit card form. It cannot navigate a billing portal, complete a CAPTCHA, or respond to a fraud-detection phone call. Traditional payment flows assume a human at the keyboard. When the client is software, not a person, those flows break down.

HTTP 402 with a protocol like x402 gives agents a payment method that matches their capabilities: receive a price in a structured header, sign an authorization with a private key, attach the signature to the next request, and continue. No human intervention required. No accounts to manage. No billing cycles to reconcile.

The status code that was reserved for a future that did not yet exist in 1999 has found its purpose in an economy where the clients are no longer exclusively human.

Further Reading

• What Is x402? — The open protocol for machine-native HTTP 402 payments, including technical specification and supported networks.
• Crypto Payments for APIs — Why stablecoin micropayments are replacing API keys for autonomous agents.