iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
HTTP 402 Payment Required is still a reserved, nonstandard status code—not a built-in web checkout. Two approaches are giving it more concrete payment behavior: x402 defines a request-and-retry payment flow, while an IETF Internet-Draft proposes a payment scheme built on HTTP authentication. Both can let a service provider condition access on payment information sent with a resource request. That may give the provider more direct control over access and usage, but neither protocol decides who owns a customer’s identity, support, billing history, or long-term relationship.
What is HTTP 402 Payment Required?
402 Payment Required is an HTTP response status whose name suggests payment, but the status alone does not define a checkout process. MDN describes it as a nonstandard response code reserved for future use: there is no universal convention for what a 402 response must contain, and systems have used it in different ways. Browsers also do not provide a special 402 payment screen; they handle it as a generic client error.
| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
High Performance Browser Networking: What every web developer should know about networking and web... | $31.34 | Buy on Amazon |
| 2 |
|
Learning HTTP/2: A Practical Guide for Beginners | $18.11 | Buy on Amazon |
| 3 |
|
HTTP: The Definitive Guide | $26.04 | Buy on Amazon |
| 4 |
|
HTTP Pocket Reference: Hypertext Transfer Protocol | $6.94 | Buy on Amazon |
| 5 |
|
HTTP/2 in Action | $42.73 | Buy on Amazon |
The IETF draft behind the Payment HTTP Authentication Scheme likewise says 402 was reserved in HTTP/1.1 but never standardized for common use. The approaches described below add conventions around payment challenges and credentials; they do not turn the status code itself into a universal payment system.
Recommended Free Tools
How does x402 work?
x402 is an open payment protocol project for internet-native payments. Its documentation describes uses such as charging per API request, selling access to content, and letting AI agents pay for API access. These are documented use cases, not evidence that every service or market has adopted x402.
#1 Best Overall
- Used Book in Good Condition
- The client requests a protected resource. This could be an API endpoint or another resource whose provider requires payment.
- The server returns a payment challenge. It responds with HTTP 402 and provides payment requirements in the
PAYMENT-REQUIREDheader. - The client selects an offered option and retries. It sends payment information in a
PAYMENT-SIGNATUREheader. - The payment is checked and settled. The resource server may verify the payment itself or use a facilitator; settlement may also be handled by the server or facilitator.
- The server returns the result. If the payment succeeds, the server provides the resource. The HTTP transport can include a
PAYMENT-RESPONSEheader with settlement information.
The x402 transport specification defines these headers as the places for the payment requirements, payment payload, and settlement response. Cloudflare’s Monetization Gateway documentation describes an implementation using x402 version 2 and says it does not serve the protected resource if verification or settlement fails. That is an implementation example, not proof that every x402 deployment behaves identically.
What is the Payment HTTP Authentication Scheme?
The IETF Internet-Draft proposes a different way to express payment through HTTP authentication. A server presents a payment challenge in WWW-Authenticate, and the client returns payment authorization data in an Authorization header using the Payment scheme.
Rank #2
The draft is payment-method agnostic. It sets out a framework with payment method identifiers, while separate method specifications are expected to define concrete payload formats and how verification and settlement work. In other words, the authentication scheme describes how a payment challenge and credential fit into HTTP; it does not by itself choose a payment network or fully define a transaction.
This is not simply another name for x402. The approaches use different header conventions and structures, and the IETF draft is not a finalized standard. The reviewed draft version listed an expiry date of September 19, 2026; that date has passed. Its authors include people affiliated with Tempo Labs and Stripe, but its status on October 9, 2026 cannot be established from that expired version alone. A reader implementing against it should check the IETF Datatracker for a successor or revised draft.
Rank #3
How do x402 and the IETF draft differ?
| Question | x402 | Payment HTTP Authentication Scheme |
|---|---|---|
| How is the challenge expressed? | HTTP 402 with payment requirements in PAYMENT-REQUIRED. |
An HTTP authentication challenge using WWW-Authenticate: Payment. |
| How does the client present payment data? | In a PAYMENT-SIGNATURE payload. |
In an Authorization: Payment credential. |
| How are payment methods handled? | The project describes extensible schemes and networks, with versioned protocol structures. | The draft defines an abstract, payment-method-agnostic framework; separate specifications define concrete methods. |
| Who defines verification and settlement? | The resource server or a facilitator can verify and settle, depending on the implementation. | The concrete payment-method specifications determine those procedures. |
| What is its documented status? | An open project protocol with versioned documentation; Cloudflare documents a version 2 implementation. | An IETF Internet-Draft, not a final standard; the reviewed version’s listed expiry has passed. |
| Does it assign ownership of the customer? | No. It can put payment and access interaction closer to the resource request. | No. It defines a payment challenge and credential framework, not a complete customer relationship. |
XEP-0518 from the XMPP Standards Foundation also names x402 and Stripe/Tempo’s Machine Payments Protocol among related approaches. It points to shared ideas such as in-band payment instructions, payment followed by a retry, and support for multiple payment options. That is useful adjacent context, but it does not make the protocols interchangeable.
Who owns the customer when an AI agent pays an API directly?
Neither protocol defines “customer ownership” as a technical property. The practical effect depends on what ownership means and on the rest of the service around the payment exchange.
Rank #4
| Dimension of the relationship | What an in-request payment flow can change | What the protocol does not settle |
|---|---|---|
| Access and price terms | The resource provider can present terms at the point where a client requests a resource and decide whether to serve it. | Whether a marketplace, agent platform, or other intermediary controls discovery or sets additional access policies. |
| Usage interaction | The provider can receive payment-related information alongside a request and may observe requests it serves. | Whether the provider can identify the person or business behind an agent, or retain and use data under particular policies. |
| Identity and authorization | Payment data can be part of the access flow. | Who authenticates the human or organization, manages permissions, or links multiple agents and accounts to one customer. |
| Billing and ongoing relationship | A provider can charge at request time rather than requiring every access event to begin in a subscription portal. | Who keeps billing records, issues invoices, handles refunds, manages repeat relationships, or provides customer support. |
The business inference is that these patterns may give a service provider more direct control over access and usage. A seller of an API, dataset, or article may be able to state an acceptable price in the request flow and serve software agents as well as people, without first relying on an account or subscription portal. The x402 project describes buyers and sellers interacting directly through HTTP requests, with payment handled through the protocol. That describes the request flow; it does not prove that intermediaries lose control of the broader customer relationship.
An intermediary may still own discovery, identity, wallet access, authorization policy, currency conversion, settlement, tax handling, fraud controls, disputes, or support. A resource provider may directly process a request without knowing who operates the agent behind it. “Who owns the customer?” therefore has several answers: the provider may control access, while another company controls identity, billing, or the ongoing human relationship.
Best Value
Does x402 make payments free?
No. The x402 project says its protocol layer has zero fees, while its site notes that payment-network fees still apply. That is a project claim about the protocol layer, not a claim that completing a payment costs nothing or that x402 is cheaper than cards, subscriptions, or other payment rails. Conversion costs, refunds, compliance work, and payment risk are separate considerations.
More generally, placing payment in an HTTP request does not remove the need to decide who bears payment-network costs, who handles failed or reversed transactions, what records are kept, or how customers get help. Those responsibilities depend on the payment method and business arrangement around the protocol.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
