The 402 (Payment Required) HTTP Status Code

Introduction says that "The 402 (Payment Required) status code is reserved for future use." To accommodate emerging experimental uses of this status code, defines the status code and establishes guidelines for its use.

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

402 Payment Required The 402 (Payment Required) status code indicates that the resource requires payment before it will satisfy the request, and that no acceptable payment has been made. This status code does not indicate the form of the payment, what it covers (e.g., one request, a period of access, or a set of resources), or whether an earlier payment was attempted and found unacceptable. Therefore, a server generating a 402 response SHOULD indicate how a payment can be made, so that clients can make a payment and retry the request. This might be done using header fields () and/or the response content (). Any server can generate this status code, including an intermediary () that requires payment for forwarding the request. A 402 (Payment Required) response is not heuristically cacheable ().

IANA Considerations IANA should update the Hypertext Transfer Protocol (HTTP) Status Code Registry to refer the entry for the 402 status code to this document upon publication.

Security Considerations HTTP does not authenticate the sender of a response beyond what the underlying connection provides, and a 402 (Payment Required) response can be generated by an intermediary () as readily as by the origin server. An attacker who can insert or modify responses can therefore substitute their own payment information and have the payment directed to them, or can demand payment where none was required. Clients SHOULD NOT act upon payment information in a response that was not received over an authenticated connection (see ). More generally, a resource can demand an arbitrary amount for any request, and can demand payment again after one has been made; clients that pay without direct human involvement need constraints on how much, how often, and to whom they will pay. Payment requirements often depend on who is asking and what they have already paid, so 402 (Payment Required) responses might carry client-specific information -- amounts owed, transaction references, or identifiers for the payer. Servers need to prevent such responses being stored and reused for other clients by a shared cache, either by making them uncacheable or by using Vary (); note that Vary can only be keyed on request header fields, so a requirement that depends on state not carried in the request cannot be expressed that way. Making a payment can also link a client's requests to a payment instrument, and thereby to a person, so a client that is otherwise unidentified should treat the decision to pay as one that discloses identity.