Summary

  • RFC 2068 put 402 Payment Required in HTTP/1.1 in January 1997, then gave it one instruction: “reserved for future use.”
  • RFC 2616, RFC 7231 and the current RFC 9110 carried that reservation forward. HTTP still gives developers no shared price, payment challenge or settlement contract for 402.

A code with a sign and no counter

An engineer wiring an international checkout can receive 402 Payment Required and still have to ask four questions: how much, in which currency, for whom and what proves payment? The status names a gate; it gives the client no shared way through it. HTTP wrote down the payment condition, then left each application to build the checkout.

HTTP/1.0’s RFC 1945 explained status codes as machine-readable results and listed its recognized values. The familiar run jumped from 401 Unauthorized to 403 Forbidden; 402 was absent from that list. The document allowed extension codes, so an unlisted number was possible. It simply had no defined place in that first published catalogue. RFC 1945 §§6.1.1–6.1.2

The January 1997 HTTP/1.1 specification made the number visible. RFC 2068 added 402 Payment Required to the status-code grammar and gave it section 10.4.3. The entire rule was one sentence: “This code is reserved for future use.” The label announced a financial gate; the normative text supplied no gate machinery. RFC 2068 §§6.1.2, 10.4.3

A status line can tell a program what broad result arrived. It cannot settle a bill by atmosphere. The 402 definition specifies no amount, currency, payee, payment credential, confirmation, settlement or dispute path. A response body could explain an application’s own terms, but HTTP does not make those terms portable between clients and servers.

401 got a challenge. 402 got a waiting room.

The neighboring 401 shows how a shared interaction can be written down. RFC 9110 requires a 401 response to include WWW-Authenticate with at least one applicable challenge. A client can inspect the scheme and decide how to obtain credentials. Section 15.5.3 gives 402 none of that. It repeats the reservation and stops. RFC 9110 §§15.5.2–15.5.3

That gap has an owner. If a site wants to put a resource behind payment, its application must decide what is owed, how the buyer proves payment, which party accepts it and what happens after rejection or a failed settlement. The protocol’s number can mark a refusal. The application still has to build the checkout.

The future kept getting rescheduled

RFC 2616, published in June 1999, repeated the same sentence in section 10.4.3. RFC 7231 did so in 2014. RFC 9110 did so again in 2022. The section number moved; the reservation stayed. Each revision updated HTTP’s semantics while carrying the payment placeholder into the next edition. RFC 2616 §10.4.3 · RFC 7231 §6.5.2

The RFCs do not name the payment system their authors expected. A dated design record identifying one would change that history. The published standards give the code’s label and preserve its open status; they do not provide a missing origin story.

The IANA HTTP Status Code Registry, accessed for this article and last updated 15 September 2025, still lists 402 as “Payment Required” and cites RFC 9110 §15.5.3. IANA HTTP Status Code Registry

A status number cannot standardize the bargain

That is where the economics of a developer interface shows up. A shared protocol can save every implementer from negotiating the same mechanics in a separate manual. HTTP’s 402 does not do that work. The buyer’s client and the server operator need an application-level agreement about price, proof, credentials, retries and finality. Developers absorb the integration and maintenance cost, while each service keeps control of its own terms.

The code is therefore useful as a name for a condition and incomplete as a payment interface. It tells a client that the server has attached payment to access. It does not give the client a common way to satisfy that condition. In HTTP, the checkout remains local policy wearing a standard number.

Sources