Definition
HTTP 402 Payment Required means the requested resource cannot be provided until a payment condition is satisfied. It is listed in the official HTTP status code registry, but historically has not had one universal standard behavior across browsers and websites.
HTTP status codes are short numeric messages that tell a client what happened after a request. Codes in the 400 range generally describe client-side problems or access conditions. HTTP 402 belongs to that family, but unlike common codes such as 401 Unauthorized, 403 Forbidden, or 404 Not Found, 402 was reserved for payment-related use.
Official Status
The IANA HTTP Status Code Registry lists 402 as Payment Required and references RFC 9110, section 15.5.3. That means 402 is not an invented number. It is part of the registered HTTP status-code space.
However, MDN describes HTTP 402 as a nonstandard response status code reserved for future use. MDN also explains that the code was created for digital cash or micropayment systems and that no standard use convention exists across the web.
That distinction matters: HTTP 402 is officially registered, but practical behavior is not universal. Different services may use it differently unless they are following a specific protocol such as x402.
Why HTTP 402 Was Created
HTTP 402 reflects an early idea: the web might eventually support paid access directly through normal request and response flows. A browser, application, or software client could request content, learn that payment was required, make payment, and then access the resource.
That idea was ahead of the everyday web. Credit cards, subscriptions, logins, app stores, ad-supported publishing, and custom payment systems became the dominant pattern instead. As a result, HTTP 402 remained more of a reserved placeholder than a widely standardized user-facing browser feature.
Why It Was Rarely Used
HTTP 402 did not become common because the web never adopted one universal payment negotiation method around it. Payment is not just a status code problem. It requires identity, pricing, currency, fraud handling, refunds, authorization, delivery guarantees, user consent, receipts, and dispute handling.
Without an agreed payment flow, a 402 response by itself does not tell a browser exactly what wallet, payment rail, token, currency, or checkout method should be used. That is why many systems historically used custom paywalls, account billing, API keys, subscription dashboards, or ordinary payment pages instead.
How A 402 Flow Can Work
A modern 402-style flow usually needs extra instructions beyond the number itself. The server must tell the client what payment is required, how to pay, and how to prove payment.
GET /api/paid-resource
HTTP/1.1 402 Payment Required
Content-Type: application/json
{
"error": "payment_required",
"amount": "0.01",
"currency": "USDC",
"resource": "/api/paid-resource"
}
How x402 Revives The Idea
x402 is one modern attempt to make the 402 idea practical for APIs and machine-to-machine access. Instead of relying on a human checkout page, an x402-style flow lets a client receive payment instructions, submit payment information, and retry or continue the request after verification.
This is especially relevant for AI agents because agents need structured, machine-readable flows. A human can click buttons and complete a checkout form. An AI agent or automated dashboard needs an API-level way to understand that payment is required and what to do next.
That is why KepAIx treats HTTP 402 and x402 as connected but separate educational topics: HTTP 402 is the status-code foundation, while x402 is a practical protocol ecosystem that builds on the payment-required idea.
How KepAIx Uses This Concept
KepAIx uses the HTTP 402 idea through x402-powered developer access. The purpose is educational: to show how AI intelligence resources can be exposed to developers, dashboards, and AI-agent workflows through machine-payable API access.
KepAIx should not describe HTTP 402 as a universal browser payment standard. It should describe HTTP 402 accurately as the Payment Required status code, then explain that x402 gives developers a more specific pattern for using the payment-required idea in API environments.
Developer Notes
Developers should treat HTTP 402 as a signal, not a full payment system. A complete implementation needs clear response bodies, supported currencies or networks, replay protection, payment verification, error handling, and a way to return the requested resource after payment succeeds.
In practical API design, 402 can be useful when the client is expected to understand a payment-required flow. If the client is a normal browser user, a traditional payment page or account flow may still be clearer. If the client is an API client or AI agent, x402-style structured responses can make the flow more machine-readable.
Important Limitations
HTTP 402 alone does not define how much to pay, where to pay, how to prove payment, what happens after payment, or how disputes and failed payments should work. Those details belong to the payment protocol, resource server, facilitator, wallet, network, or application design.
For that reason, the safest educational wording is: HTTP 402 provides the Payment Required status-code concept; x402 and related implementations provide a more complete way to use that concept in machine-payable API flows.
FAQ
References
These references are included to keep this page grounded in public, checkable sources.
Next Step
After understanding HTTP 402, the next step is x402. HTTP 402 explains the payment-required status-code concept. x402 explains how that idea can become a practical machine-payable API pattern.