402 Payment Required: The Status Code the Web Reserved for Thirty Years

In January 1997, the authors of the HTTP/1.1 specification were enumerating the status codes a web server might return. Most of them have become part of the furniture of the internet: 200 for success, 404 for a page that is not there, 500 for a server that has given up. Between the code for a malformed request and the code for a forbidden one, they wrote down a third, gave it a name, and then declined to define it.

402 Payment Required. This code is reserved for future use.

It has said essentially that ever since. Through HTTP/1.1's revision in 1999, through two decades of the commercial web, and into the current specification published in 2022, which still describes 402 as reserved. The people designing the protocol clearly believed the web would need a native way for a server to say this costs money — they left the door framed and hung. Then nobody built the room behind it for close to thirty years.

It is worth understanding why the room stayed empty, because the reason is not that the idea was bad. It is that the web solved payment by going around the protocol instead of through it, and that detour worked well enough for exactly as long as every buyer was a human being.

What a Card Payment Actually Requires

Consider what has to be true before a conventional online payment can happen. There must be an account, created by someone filling in a form. There must be a billing relationship, established in advance and tied to a legal person with a name and an address. There must be an instrument — a card issued by a bank to that person after its own checks. There must be a dispute process, because card payments are reversible by design, which means there must be somebody to adjudicate the reversal. And underneath all of it there is a cost floor: the fixed per-transaction fee that makes a thirty-cent payment uneconomic and a thousandth-of-a-cent payment absurd.

Every one of those requirements assumes a human. Not metaphorically — structurally. A form is a thing a person fills in. An account is a relationship a person enters. A chargeback is a complaint a person makes. The entire apparatus is built around an identified individual who can be billed, trusted, and later held responsible.

Given that, the web made a sensible choice. Rather than teaching the protocol about money, it moved payment up into the application layer, where the human already was. Stripe, PayPal, and everything like them are genuinely excellent engineering, and they are all built on top of HTTP rather than into it. A payment became a flow of pages you walked a person through, not a property of a request. Status code 402 was not rejected. It was simply routed around, and the detour was invisible because there was always a person available to walk it.

Attempts to fill the gap directly kept failing, and their failures are instructive. Digital-cash systems in the 1990s had working cryptography and no merchants. Micropayment schemes foundered on the observation that asking a human to make a conscious decision about a fifth of a cent costs more in attention than the payment is worth. The recurring lesson was that the bottleneck was never the money. It was the human in the loop, whose time was too expensive to spend on small decisions and whose participation every payment system required.

The Assumption Breaks

Software that can decide to buy something changes that calculation completely, and it does so from both ends.

An AI agent cannot fill in a signup form in any meaningful sense. It cannot sit through a sales call, agree to terms on its own behalf, or hold a card in its own name — and it should not, since the legal and practical consequences of giving autonomous software a general-purpose payment instrument are not ones anybody has worked out. Yet an agent performing real work runs into paid resources constantly: an API with a per-call price, a data set, a computation, a service that costs two dollars. Under the existing model, every one of those is a hard stop that requires a human to go and establish a relationship in advance.

Meanwhile the other constraint inverts. The reason micropayments failed — that a decision costs more than the payment — does not apply to software. An agent can evaluate a price, decide, pay, and continue in the time it takes to complete a network round trip. The attention cost that killed every previous attempt goes to approximately zero.

So the conditions that kept 402 reserved have both changed at once. There is now a buyer that cannot use the detour, and there is now a buyer for whom the small-payment economics work.

How x402 Fills the Slot

The mechanism is almost disappointingly simple, which is usually a good sign.

An agent requests a paid resource in the ordinary way. The server responds with 402 and, in the response, its payment requirements — what this costs and how to pay it. The agent signs a payment authorization and retries the same request, carrying the authorization in a header. A facilitator verifies and settles it, and the server returns the resource with a 200. Four steps, all inside HTTP, no pages, no redirect, no browser.

Settlement is in USDC on Base, which matters for two practical reasons: it clears in seconds rather than days, and the amounts can be small enough that a per-call price of a few cents or a few dollars is not swallowed by fees. There is no prior relationship to establish, because the payment is the relationship. That single property is the one that makes the difference: payment and setup become the same step. An agent that has never encountered a service before can discover its price, pay it, and use it, without anything having been arranged by a human in advance.

Byte Federal operates as an x402 facilitator — the component that verifies and settles those payments on behalf of a service. If you are building an API that ought to be able to charge software directly, that is the piece you would otherwise have to build yourself.

The Harder Half

Everything above is the part that gets attention, and it is the less interesting half of the problem.

Give software the ability to spend money and you have not merely added a feature; you have changed what a mistake costs. Until now, the worst outcome of a confused agent was a wrong answer. An agent with a wallet can take actions that do not come back. And the same irreversibility that makes settlement fast and cheap — no chargeback, no clearing house, no reversal — means there is no adjudicator to appeal to afterwards. We have written at length about why hard money has no refund, and it applies here with full force: the finality is a feature you are buying deliberately, and it is also the thing that will hurt you.

This is why the interesting engineering question is not how does an agent pay. It is what should an agent refuse to do on its own.

An autonomous workflow needs somewhere to stop. Not a blanket requirement that a human approve everything, which destroys the point of automation, but a specific, structured pause at the irreversible step — and crucially, a way for the software itself to decide when to take it. A capability an agent can invoke, evaluate, and act on without waking anybody up unless the answer is wrong.

That is the design behind ByteVerify, and the reason it lives on the same site as the payments work rather than being filed under compliance. An agent about to send a deposit to a counterparty it has only ever met as a chat account can request a live face-to-ID check, pay the two dollars over x402, send the link, and wait. The person scans their face and their government ID on whatever phone they have. About a minute later the agent receives verified, failed, or expired by signed webhook, and proceeds or does not. One payment maps to exactly one check, so a retried request is safe — which matters more than it sounds when the caller is software that retries on timeout.

The two halves are the same idea seen from opposite sides. x402 lets software pay for things. ByteVerify lets software insist on a human before it does something it cannot take back. Neither is very useful alone, which is why the empty 402 slot and the unsolved problem of remote identity have turned out to be the same problem at different layers.

The Third Leg: Discovery

There is a prior step that is easy to overlook. Before an agent can pay for something or verify someone, it has to be able to find out what exists.

The Model Context Protocol has become the common answer — an open standard for exposing tools and data to AI assistants in a form they can discover and call directly, rather than by scraping a website built for eyes. Byte Federal runs an MCP server that exposes the kiosk network as four tools: find the nearest machines by address, city, or coordinates; read a specific kiosk's address, hours, and photos; check opening status across an area; and list a city's machines. An assistant connects to it and can answer "where can I do this, right now, near me" without anybody writing a scraper that breaks when we change our markup.

Discover, transact, verify. Three open protocols, none of which we invented, doing the three things software needs to do to act in the physical economy rather than merely describe it.

What Is Genuinely Unsettled

I would rather state the open problems than pretend this is finished, because it plainly is not.

Agentic commerce is early, and a great deal of what is written about it is speculative. The number of production systems where software autonomously pays software today is small, and anyone telling you the pattern is proven is describing a projection.

The security model is the real work, and it is not done. An agent that can spend money is an agent that can be manipulated into spending money, and the manipulation surface for language models — prompt injection through retrieved content, poisoned tool descriptions, instructions hidden in a document the agent was asked to summarize — is an unsolved problem that the payment capability turns from embarrassing into expensive. Anyone deploying this needs hard budget caps enforced outside the model, scoped credentials, allowlists for what can be paid and to whom, and the assumption that the agent will at some point be successfully lied to. Those controls belong in the surrounding system, because they cannot be reliably implemented by asking the model nicely.

And the verification step, while it addresses the largest failure mode, is narrow by construction. A verified result establishes that a live human held a physical government ID whose portrait matched their face. It does not confirm the document is genuine or currently valid, does not resolve who the person is, does not screen against sanctions or watchlists, and does not establish that the person is authorized to do what they are about to do. It is one signal inside your controls. Everything the result does not cover remains yours to handle.

The Room Behind the Door

There is a particular pleasure in watching a thirty-year-old reservation finally get used for what it was reserved for. The people who wrote that line in 1997 could not have anticipated stablecoins, or language models, or software that shops. What they could see was that a protocol for transferring documents over a network would eventually need a way to say this one costs something, and rather than guess at the mechanism, they left the number unallocated and moved on.

That turns out to have been the right call, because the mechanism that works was not available to be invented until three separate things existed at once: a settlement layer fast and cheap enough for small payments, a buyer whose attention is free, and a reason for that buyer to exist at all. All three arrived in roughly the same eighteen months.

The thing to keep hold of is that payment was never the hard part. The hard part is the same as it has always been — knowing whether there is anyone real on the other side of the transaction, and deciding what you are willing to do before you find out. We are about to hand that judgment to software. It should get the same checkpoint we would want ourselves.

References

HTTP/1.1 status code 402 as reserved: RFC 2068 §10.4.3 (1997), RFC 2616 §10.4.3 (1999), and RFC 9110 §15.5.3 (2022). x402 is an open standard for HTTP-native payments; Byte Federal operates as a facilitator, with settlement in USDC on Base. The Model Context Protocol is an open standard for connecting AI assistants to external tools and data. Byte Federal's MCP endpoint, x402 facilitator details and agent-readable documentation are at bytefederal.ai. ByteVerify is a supplemental risk signal and is not an identity, sanctions, AML, KYC, or background-screening service; laboratory figures for the underlying liveness and matching technology are as published by that technology's vendor from NIST/NVLAP-accredited testing under ISO/IEC 30107-3 and ISO/IEC 19795-2, and describe the technology rather than an audit of Byte Federal's deployment.