HTTP has had a status code for “Payment Required” since the late 1990s. Code 402 was reserved for a future where paying for something on the web would be as simple as asking for it. For a quarter of a century nobody used it. The web paid for itself with advertising, subscriptions and paywalls instead, because there was no practical way to charge someone a few cents.

That has changed. Over the past year I have built several things on top of 402, and the economics are what convinced me it is real.

The arithmetic of a one-cent sale

A typical card payment carries a fixed fee of around 30 cents before the percentage is applied. Fees vary by provider and country, but the shape is the same everywhere: card economics assume a basket worth tens of dollars. Sell something for one cent on a card and you lose money on every sale.

Now look at who is starting to buy. An AI agent doing research doesn’t buy a subscription. It buys one API call, one document, one signature, one photo. Run the numbers on a modest deployment: 1,000 agents each making 20 paid calls a day at one cent per call is $200 of revenue. On cards, those 20,000 transactions would cost about $6,000 a day in fixed fees alone. The business doesn’t exist.

Settle the same calls in a dollar stablecoin on a fast chain, and the network fee is a fraction of a cent. A one-cent sale is profitable. That single fact opens up a category of commerce that couldn’t exist before: pricing by the call, the page or the second.

What x402 adds

Cheap settlement on its own isn’t enough. The other missing piece was a standard way for a server to say “this costs money” and for a client to pay without a human filling in a form. That is what x402 does.

The flow is short:

  1. A client asks for a resource.
  2. The server answers 402 Payment Required with a machine-readable price: how much, in which asset, on which network, paid to which address.
  3. The client signs a payment for exactly that amount and repeats the request with the payment attached.
  4. The server checks the payment, settles it and returns the resource.

No account, no API key, no invoice. The price and the payment travel with the request. A piece of software can discover a paid API and start using it in the same second, which is exactly what an agent needs. x402 started at Coinbase and is now stewarded by the x402 Foundation, which matters for adoption: nobody wants to build commerce on a protocol one company controls.

What I learned running x402info

I built x402info as a reference site for the protocol, and two tools on it taught me more than the reading did.

The validator sends an unpaid request to any endpoint and grades the 402 challenge it gets back: the status code, the payment requirements, the network, the amount, the pay-to address, the version and CORS. The registry health-checks every known x402 endpoint around the clock and shows which ones really return a 402, what they charge, on which network, and how reliable they are.

The pattern is consistent. Getting a 402 response out of a server is easy. Getting one that a client can act on safely is harder: the right network named, an amount that matches the documentation, headers a browser-based agent can actually read. The protocol is simple, so the quality of implementations is what decides whether agents can rely on it. Tooling that checks an endpoint before an agent pays it will matter as much as the protocol itself.

Stablecoins as one more rail

I spend my working days on settlement at scale, and my view of stablecoins comes from that seat. A stablecoin is not a new product that replaces everything else. It is one more rail, with its own strengths: it settles in seconds, at any hour, for tiny amounts, and software can program it. Cards, account-to-account payments and wire transfers keep their strengths too.

The interesting design question isn’t “crypto or not”. It is which rail fits which payment, and how to keep one set of rules in front of all of them. A one-cent API call belongs on a stablecoin. A $2,000 purchase probably belongs on a card, with its chargeback rights. A payment to a family member abroad might start as a stablecoin and end as local currency in a mobile wallet. The systems that win will route between rails, not bet on one.

What still has to be solved

Cheap settlement and a price in a header get you a working payment. They don’t get you a safe one. When software pays, someone still has to decide how much it may spend, on what, and for how long. The seller may need to know something about the buyer, such as their age or that they are a real business, without learning everything. And when something goes wrong, there has to be a record that explains who allowed what.

That is the part I find most interesting, and it’s why I built Dualwire, a working prototype of a payments gateway for AI agents. I write about what it taught me in the next piece.

Views are my own and do not represent my employer.