RFC 9110 402 Payment Required: Reserved for Future Use

RFC 9110 section 15.5.3 contains exactly one sentence: the 402 Payment Required status code is reserved for future use.

What does RFC 9110 section 15.5.3 specify for 402?

RFC 9110 section 15.5.3 assigns status code 402 the description Payment Required, yet reserves the entire code for future use in one sentence. The core specification omits wire headers, payment mechanics, challenge payloads, and client retry rules, leaving all practical transaction requirements to external protocols.

The primary specification RFC 9110, Section 15.5.3 belongs to "HTTP Semantics" (STD 97), published in June 2022 by editors R. Fielding, M. Nottingham, and J. Reschke. This document obsoletes RFC 7231 and earlier revisions. You can inspect the complete standard at RFC 9110 text, where the index records: "402 Payment Required (status code)".

The entire normative text of section 15.5.3 states:

"The 402 (Payment Required) status code is reserved for future use."

That single sentence is the full text. Contrast this definition with section 15.5.4 directly below it. Section 15.5.4 defines 403 Forbidden across several detailed paragraphs. It outlines authorization boundaries, credential checks, and explicit conditions where clients halt repeated attempts. Section 15.5.3 omits that depth. It specifies zero request lines, zero response headers, and zero configuration keys. The section contains zero sample messages. When your client receives a bare 402 code, standard HTTP leaves the resolution path completely to external rules.

What does the IANA status code registry record for 402?

The IANA HTTP status code registry records value 402 with the name Payment Required and points directly to RFC 9110 section 15.5.3. The registry entry omits the reservation phrase, requires formal IETF Review for future changes, and defines zero operational fields for client transactions.

According to independent evidence recorded in the IANA HTTP Status Code Registry, the status table entry was last updated on 2025-09-15. The registry table assigns value 402 the title "Payment Required" and references "RFC9110, Section 15.5.3". It omits the phrase "reserved for future use" from the title column.

Section 16.2.1 of RFC 9110 specifies that IANA maintains the official status code registry. Each entry requires a 3-digit status code, a short description, and a pointer to specification text. Adding or altering entries in this namespace requires formal IETF Review. The registry confirms that status 402 remains allocated, while its referenced specification points to the single reservation sentence.

Why does a 402 status code lack a built-in payment protocol?

A raw 402 status code signals that access requires settlement, but leaves all payment execution details to external API specifications. Because the standard omits transaction mechanics, your client requires explicit documentation from the endpoint provider to discover payment methods, required tokens, and settlement confirmation headers.

The core HTTP standard omits specifications for tokens, microtransactions, payment processors, and settlement ledgers. Section 16.2 provides registration rules for status codes, while leaving payment semantics undefined for status code 402. The code received its reservation decades ago and retains that status under STD 97.

Because the core specification defines zero wire schemas, working architectures build custom protocols on top of 402. For example, our review of x402 V2 examines an active implementation that establishes distinct header names and protocol contracts between V1 and V2. In these implementations, the API creator supplies the payment requirements, rather than the IETF specification.

When running autonomous agents and local toolchains, unhandled 402 responses can stall execution loops. If an agent encounters an undocumented paywall without parseable headers, it wastes tokens repeating rejected calls. For multi-model setups, implementing AI agent cost control helps track outbound tool spend. Combining that monitor with BMD, see what your agents actually did lets you inspect API call logs and trace blocked requests. When executing model calls on your own hardware using our 5090 local inference guide, your local compute remains free of per-token API charges, while external paid tool endpoints still require strict header verification.

What should you do with this?

You should treat incoming 402 responses as custom provider signals rather than standard protocol handshakes. Inspect response headers for vendor payment schemas, confirm billing requirements before sending transactions, and enforce strict execution budgets in your client code to protect automated agent pipelines.

Follow these three steps in your setup:

1. Inspect response headers for custom payment specifications. When an API returns 402 without vendor headers, halt further requests because RFC 9110 specifies zero built-in retry mechanisms.
2. Validate required payment schemas against service documentation. When integrating endpoints that implement protocols like x402, parse the required header fields before constructing payment tokens.
3. Configure hard execution limits in your client code. Halt automated agents when receiving a 402 code until explicit payment confirmation appears in the response.

Accompanying prompt

What the prompt does: Inspect an API endpoint returning status code 402 to confirm whether it supplies custom payment headers or only the RFC 9110 reservation.

Copy/paste this prompt:

Copy-ready prompt

Paste the exact block into your coding agent.

No article chrome, no footnotes, no formatting drift.

Copy promptSelect text

Role: API Integration Auditor Context: You evaluate an HTTP endpoint returning status code 402 to determine if it defines custom payment parameters or relies strictly on the RFC 9110 reservation. Inputs: - Endpoint URL: __ - Response headers: __ - Response body: __ Task: 1. Compare response headers against RFC 9110 section 15.5.3 reservation text. 2. Identify missing payment fields required to repeat the request. 3. Produce a structured verification report based on the response headers and response body. Output: - Summary of payment metadata presence - List of missing payment instructions - Recommended handling strategy Constraints: - Rely strictly on provided response headers and response body - Reject assumed payment protocols absent from headers - Keep findings factual and concise

25 lines/799 chars

Ready

This prompt and every other one we publish live in the free prompt library.

Copy the block above.

Weekly measured local runs: https://bmdpat.com/5090-reports