Somewhere Over the Rainbow, HTTP 402 Found a Purpose

There is suddenly a lot more activity around paid access on the web than there was even a year ago - we have not one, but two proposals related to paid access submitted to the IETF on the same day. That is not because the old dream of “micropayments” has finally been solved. It is because agents are making the problem harder to ignore.

If software is going to browse, fetch, summarize, compare, quote, and act on information at scale, then the old binary of “open page” versus “closed paywall” stops being enough. Origins need a machine-readable way to say not just no, but under what terms. And clients need a machine-readable way to say not just I want this, but here is what I am willing to do in order to get it.

That is why HTTP 402 is suddenly back in the conversation. The recent wave includes Mike Dierken’s new Conditional Access for HTTP draft, the new Payment HTTP Authentication Scheme draft, Coinbase’s x402, Lightning’s L402, and, as an older precursor worth remembering, the 2015 Content Passes proposal from the web-platform world. They do not all solve the same problem, and that is exactly the point.

At first glance, this can look like a familiar standards food fight: crypto versus cards, old web versus new agents, one wire format versus another. That is not quite right. The more interesting distinction is simpler.

Some of these approaches are really about payment.

Others are really about agreement.

That difference turns out to matter more than almost everything else.

The first split: micro-payment versus micro-agreement

The term “micropayment” has always done a little too much work. It makes people think of tiny transfers of money happening inline, at the moment of access, on a per-request basis. Some of the new 402 proposals really do lean in that direction. The Payment auth draft is explicitly structured as a challenge-and-response flow: the server returns 402 Payment Required with a WWW-Authenticate: Payment challenge, and the client retries with proof that the payment condition has been satisfied. x402 and L402 are also, in different ways, built around proving paid entitlement before access is granted.

Conditional Access is different. It is better understood as a protocol for micro-negotiation and micro-agreement. The origin (ie. the server) publishes terms. The client expresses the bounds under which it is willing to accept the response. If the terms line up, the resource is served. The draft is explicit that it is not defining payment execution. It is defining the conditions under which access is granted.

That is not a weaker version of payment. It is a different primitive.

A micro-agreement says: I accept access under these terms. A micro-payment says: I have already transferred, or can prove transfer of, value under these terms.

Those are related, but they are not the same event.

And once that is clear, another lens comes into focus.

Pre-pay versus post-pay is really another way of seeing the same divide

Most payment-auth schemes are, by design, more comfortable with pre-pay or at least prove-pay-now access. The client presents something that shows entitlement already exists, or can be immediately verified, and the origin serves on that basis. That makes sense if the whole point is to keep the access decision tightly coupled to settlement.

Agreement-based approaches are more naturally at home in a post-pay or settle-later world. If the important thing on the request path is that both sides can clearly express and accept terms, then actual settlement can happen elsewhere: against a wallet, against a balance, against a customer account, against an invoice, or through some later reconciliation process. That is the real attraction of the agreement model. It keeps the hot path about consent and conditions, not necessarily about moving money.

That said, it would be too neat to say one side is “pre-pay” and the other is “post-pay” full stop. Reality is messier than that. An agreement system still needs some machinery in the background to make the agreement economically meaningful. A payment-proof system can still front a credit relationship or a standing balance. The distinction is not absolute. But it is still useful, because it reveals what each design is optimizing for.

One side wants access to depend on proof of settlement.

The other wants access to depend on clear agreement now, with settlement handled by a composable layer.

Anonymity looks like a major difference, until you look closer

At first glance, the payment-proof camp can seem more anonymity-friendly. x402 makes a big deal of enabling access without accounts or sessions. L402 is also comfortable with payment-derived entitlement rather than stable client identity. And in the abstract, that sounds right: if the origin only needs proof that somebody paid, maybe it does not need to know who the requester is.

Meanwhile, agreement-oriented approaches can seem more identity-heavy, because billing and reconciliation often imply a known customer relationship. Conditional Access itself even says that conditional access based on economic or policy conditions will typically require identifying the client.

But the closer you look, the less dramatic this difference becomes.

A payment token does not automatically tell you who the caller is. At most, it tells you that this request carries some valid proof of paid entitlement, and in some systems not even that much about the payer as a durable identity. That may be entirely fine. Plenty of origins care more about whether access is authorized and compensable than about whether the request maps cleanly to a named principal.

On the other side, “identifying the client” does not necessarily mean strong real-world identity. It could mean a pseudonymous account, a prepaid wallet, a delegated agent identity, or some other stable handle good enough for billing and abuse control.

So the more honest conclusion is that anonymity is not really owned by either side. It is mostly a policy choice that can be layered onto both. Some architectures make it easier to support anonymous or semi-anonymous operation. Some make it easier to support customer-level reconciliation and differentiated policy. But neither camp has a monopoly on privacy, and neither one automatically solves identity.

That is worth saying plainly because a lot of confusion in this space comes from mixing up three different questions:

Who is calling?Who is paying?What proof does this request carry?

Those are related, but they are not interchangeable.

The most practical distinction: one hit or two

This is where the architecture becomes concrete.

Challenge-based payment flows usually mean two hits in the base case. The client requests the resource. The server responds with 402 Payment Required and the details of how to satisfy it. The client completes the payment step and retries. The Payment auth draft is built this way. x402 is generally built this way. L402 is also, at least for first access, built around a challenge-then-proof pattern.

Conditional Access has a cleaner story for one-hit interaction. A client can arrive already expressing its acceptable bounds, and the server can either serve or decline in a single decision point. That does not magically eliminate complexity. It moves complexity elsewhere, into prior setup, policy, credit, balances, or later reconciliation. But from the perspective of the fetch itself, it is undeniably lighter.

I do not think this is a trivial UX detail. It is one of the central tradeoffs.

Two-hit systems keep the payment transition explicit in-band. That can be cleaner from a settlement standpoint, and maybe cleaner from a security standpoint as well. But it imposes latency and protocol ceremony on every access event, or at least on every fresh entitlement event.

One-hit systems feel more web-native because they preserve the basic shape of an HTTP fetch. But they only work well when the world around them already supports standing relationships, prior authorization, or deferred settlement.

So this is not just convenience versus rigor. It is a disagreement about where the state transition belongs.

A useful aside: access is not usage

One thing these discussions often blur is the difference between access and usage.

Access is simple: should this response be served now?

Usage is everything that may happen after that: caching, reuse, downstream processing, model consumption, derived outputs, and redistribution. Those are not edge cases anymore. In the agentic web, they are often the whole point.

This matters because usage accounting is composable with either school. Conditional Access explicitly points toward a companion usage-reporting mechanism; the draft even calls out usage-log as one possible protocol for reporting downstream use. But there is nothing about usage logging that makes it exclusive to agreement-based systems. A payment-proof system can also log, report, meter, and reconcile what actually happened after access was granted.

That is why “access versus usage” should not be read as another battle line between competing 402 camps. It is a reminder that any serious paid-access architecture will eventually need more than an access gate. It will need a way to represent what happened after the gate opened.

Access decides whether a response may be served.

Usage decides how that response counts.

Those are different economic events, and they deserve different protocol layers.

What would actually make the web better

The easiest ending here would be to say that if any of these proposals succeed, then maybe micropayments finally arrive. I do not think that is quite right.

The more important prize is not a universal payment rail. It is a standard way for clients and origins to express economically meaningful intent at request time.

That is the missing piece on the web today.

Right now, paid access is usually implemented as some brittle mixture of paywalls, API keys, cookies, subscriptions, undocumented exceptions, scraping norms, and private bilateral deals. None of that composes well. None of it is legible to agents. None of it creates a healthy market in which different wallets, identity systems, billing providers, or usage-reporting layers can interoperate.

If the web got even one standard way to say either:

I am willing to access under these terms,
or
I can prove entitlement under this payment method,

that would already make the web a better place.

Why? Because it would turn paid access from an application-specific hack into a protocol concept.

That would let publishers compete on terms instead of just walls. It would let clients and agents behave more predictably. It would let intermediaries innovate on privacy, settlement, accounting, and delegation without each one having to invent an entire proprietary stack. And it would make the web more legible: not simply open or closed, but negotiable.

That is the deeper opportunity here. The future is probably not one winner. It is more likely a stack.

Agreement protocols for deciding access.Payment-proof protocols for immediate settlement.Usage-log protocols for downstream accountability.

If the web gets those pieces, in some interoperable shape, that will matter more than whether any one draft “wins.”

Because the real upgrade is not just charging for requests.

It is making economic relationships on the web explicit enough that software can participate in them without pretending everything is either free or forbidden.