HTTP 402 Explained: The Status Code That Charges You

HTTP 402 is one of the original status codes of the web: "Payment Required." It has sat in the HTTP specification since the earliest HTTP/1.1 documents, carrying a name but no agreed behavior — reserved for a future that took decades to arrive. The x402 protocol is what finally puts the code to work. This page covers where 402 came from, why nothing used it, and how x402 turns it into a functioning payment handshake.

Reserved from the beginning

When the HTTP/1.1 specification was published as RFC 2616, its authors assigned the 4xx block to client errors and carved out slot 402 with the label "Payment Required" — then marked it "reserved for future use." Successor revisions of the HTTP standard kept the code reserved rather than defining a mechanism. The reservation was a bet: the web's architects expected that a native digital payment scheme would eventually be standardized and would need a status code, so they held one in advance.

That scheme never came. While 401 ("authenticate yourself") and 403 ("you may not pass") became load-bearing parts of the web, 402 remained a stub — recognized by every HTTP library, emitted by almost nothing, and defined by no shared semantics. A server could send it, but a client receiving one learned nothing actionable: no price, no currency, no instructions.

Why nothing ever used 402

The blocker was never the status code; it was the absence of a machine-payable rail behind it. Card payments, the web's default money movement, require a human in a checkout flow: card numbers, billing addresses, fraud screening, merchant underwriting. None of that fits inside a stateless HTTP exchange, and the fixed per-transaction fees of card networks make small charges — a cent for an article, a tenth of a cent for an API call — economically absurd. So the web monetized attention and commitment instead: advertising on one side, subscriptions on the other, and 402 stayed dormant.

Individual platforms occasionally repurposed the code privately, but with no common semantics each use was a dialect. A client could not build general behavior around 402 because the next server's 402 might mean something entirely different.

How x402 activates the code

Two developments made the old reservation usable. First, stablecoins on low-cost networks — USDC on Base or Solana — made it practical to transfer a fraction of a cent between strangers without accounts or paperwork. Second, the x402 protocol, originated at Coinbase, assigned 402 concrete, machine-readable semantics: the response carries the price and payment terms as structured data, the client retries the request with a signed payment attached, and a facilitator verifies and settles the transfer on-chain.

The crucial reframing is that 402 stops being an error and becomes a challenge — the opening move of a two-step handshake rather than a dead end. A client that understands the protocol can act on it; one that does not simply sees a status code and a body it can show to a human.

The 402 lifecycle in an x402 request

1. The client sends a normal HTTP request to a paid endpoint.
2. The server replies 402 Payment Required with payment terms in the response: amount, asset, network, recipient, and payment scheme.
3. The client signs a payment matching those terms and retries the identical request with the payment attached in a header.
4. The server, via its facilitator, verifies and settles the payment, then answers 200 OK with the resource.

Because the retry is the same request plus a credential, the exchange stays idempotent in shape and debuggable with ordinary HTTP tooling — you can watch an agent get quoted, pay, and be served with nothing more exotic than a request log.

402 versus 401 and 403

The three codes answer different questions. 401 Unauthorized means "tell me who you are, then retry" — the fix is authentication. 403 Forbidden means "I know who you are, and the answer is no" — retrying changes nothing. 402 Payment Required means "identity is irrelevant; this costs money" — the fix is payment, and in x402 the payment itself is the only credential the server checks. Where 401 gates on accounts and 403 on permissions, 402 gates on value transferred, which is precisely the gate an autonomous agent can clear on its own.

See 402 responses earning revenue across the directory: browse paid data APIs, content paywalls, or the full catalog on the x402 Looker homepage.