HTTP 402 gives servers a standard way to tell clients that payment is required. AI agents are giving the long-dormant status code a practical role as protocols such as the Machine Payments Protocol make payments part of the application flow.
Some HTTP status codes show up daily: 200 OK, 403 Forbidden, and the dreaded 404. Then there is 402 Payment Required.
It has been reserved since the early days of the web, yet it almost never appears in practice. Human-friendly payment tools such as checkout pages took over, and 402 sat unused. AI agents are changing that.
Agentic commerce is giving this dormant status code a second life. With protocols such as the Machine Payments Protocol (MPP), 402 has a real path to becoming a standard signal for AI-powered transactions.
What is HTTP 402 Payment Required?
402 means a server wants payment before it hands over a resource. It sounds like it should be one of the most common codes on the web. History had other plans.
What was 402’s original purpose?
HTTP’s designers reserved 402 to make online payments simpler: one common status code that websites and APIs could use as part of a payment mechanism rather than building every flow from scratch.
Why was 402 never used?
Online payments grew up around people: subscriptions, checkout pages, and third-party gateways. Browsers never added native support for 402 or a standardized payment workflow, so the code sat idle for three decades.
Why the renewed attention on 402?
AI agents need to buy digital services without waiting for a person to click through a checkout page. A machine-readable signal such as 402 removes those manual, people-focused steps from the transaction flow.
Why AI agents create a new payment problem
Today’s payment infrastructure assumes a person is in the loop. That model worked for decades. It breaks down for agentic commerce in three ways.
API access assumes a long-term relationship
Signing up for an API usually means creating an account, entering billing details, choosing a pricing plan, and generating keys. That works for a long-term commitment. It is overkill for an agent that needs a temporary data feed. With a 402 workflow, an agent can pay for what it needs without a subscription or a stored API key.
Agents buy resources dynamically
Many agent purchases are one-offs: premium financial data, a burst of GPU compute, or a single tool call. These transactions may cost only a few cents. Subscription billing was not designed for that pattern.
The internet lacks a native payment layer
The internet has standardized protocols for sending messages, transferring files, and exchanging data between applications. Payments never received an equivalent application-layer standard. When a website or API wants to charge for access, it sends users to an external payment provider or a custom billing system. That is mildly inconvenient for a person and a major obstacle for an AI agent.
How 402 Payment Required works in modern payment architectures
Several payment protocols integrate with HTTP 402. The basic flow looks like this:
| Step | What happens |
|---|---|
| Client request | An AI agent requests access to a digital resource or API. |
| Server returns 402 Payment Required | Instead of supplying the resource, the server says the client must pay a fee. |
| Payment requirements provided | The response includes the price, accepted payment methods, and other details needed to pay. |
| Payment execution | The client completes the payment using a compatible system or protocol. |
| Resource delivered | After confirming payment, the client retries the request and receives the resource or dataset. |
Payment becomes part of the application flow
With 402, payment becomes a step inside the service’s workflow. The client can pay based on usage, and pricing can change with demand or complexity. This enables revenue models such as pay-per-request APIs that subscription billing cannot support efficiently.
How programmable protocols work with 402 workflows
402 only signals that payment is required. To communicate the requirements and confirm the transaction, servers need a programmable payment protocol such as MPP.
Why MPP works for machine-to-machine payments
Tempo and Stripe created the Machine Payments Protocol to give machine-to-machine commerce a standard payment language. Agents can understand what to pay, how to pay it, and whether the transaction is confirmed without a person approving each step. Developers set parameters such as spending limits, approved merchants, and transaction types. Agents make purchasing decisions within those bounds in real time.
The protocol has a simple, extensible core that remains neutral to the underlying payment method:
- An open standard built for the internet. MPP is an open specification proposed to the IETF, not a proprietary API. Its payment protocol specifications are public.
- Designed for payments. Idempotency, security, and receipts are first-class primitives.
- Compatible with stablecoins, cards, and bank transfers. One protocol can support payment methods and assets including USD, EUR, BRL, USDC.e, and BTC.
- Composable by design. The core can accommodate advanced flows such as disputes and additional primitives such as identity over time.
Stablecoin payments settle on a blockchain built for payments, so confirmation is independently verifiable. That control matters as agents move from single API calls to ongoing commercial relationships. MPP supports both one-off transactions and recurring sessions.
Why 402 matters beyond any single protocol
402 provides a common HTTP signal that payment is required. Programmable protocols can then define the payment flow without sending a client away from the application. The result is a reusable pattern for machine-readable payments, even when developers choose different methods and rails.
Why stablecoin payment rails are part of the conversation
402 defines how a server asks for payment. The rails underneath determine how quickly and cheaply that payment settles. As developers compare transaction fees and settlement speeds, stablecoins are a natural fit.
Internet-native payment infrastructure
Stablecoin payments move on public blockchains. They can operate across borders without bank operating hours and manual reconciliation between each intermediary. That gives machine-to-machine payments a settlement layer that is available around the clock.
Programmable money for programmable systems
Agents can make real-time decisions, such as switching APIs or datasets in the middle of a task. Their payment system has to keep up. Stablecoins let developers enforce payment rules in software, without requiring manual approval for every transaction.
Rails built for agentic commerce
Agentic commerce involves frequent, low-value transactions between systems. Traditional rails carry fixed costs and settlement delays that make this pattern difficult. Stablecoins provide global infrastructure with a settlement layer that lives in software. Learn more about how blockchain payments work.
402’s future: from placeholder to payment standard
Demand for standardized agentic payments, together with protocols such as MPP, can make 402 Payment Required a familiar part of a developer’s workflow.
Tempo co-authored MPP with Stripe and built the settlement layer underneath it. Together, MPP and Tempo’s layer-one blockchain give AI agents a path to stablecoin settlement for API access, datasets, compute, and other digital services. Contact Tempo to discuss building for the agentic economy.
Frequently asked questions
Why was 402 Payment Required never widely adopted?
The web evolved around people-focused payment tools such as checkout pages and subscriptions. Browsers never added native support for 402 or a standardized payment workflow, so the status code had no common mechanism to activate.
Why do AI agents need payment infrastructure?
Agents need to understand and pay for resources such as premium APIs or compute in seconds, without waiting for a person to complete a checkout flow.
What is machine-to-machine commerce?
Machine-to-machine commerce is software finding and purchasing digital services from other software automatically, based on programmed rules and real-time needs.
Continue learning: Microtransactions · Blockchain payments · Stablecoin payments