Imagine the following scenario: An AI agent calls a paid API. The server replies 402 Payment Required. The agent parses the challenge buried in the X-Payment-Requirements and does a sequence of actions to pay. The server replies 200 OK. The whole sequence takes 1.3 seconds.
That might sound unremarkable. It isn't.
For 29 years, HTTP had a status code designed for exactly this: "pay me, and I'll serve you." RFC 2068, published in January 1997, reserved 402 for "a future payment system." The future never arrived. That status code sat unused for so long that most browsers today don't even know what to display when they see it. They fall through to a generic 4xx error page, because nothing has ever needed it to work.
Until last year, when separate companies/projects decided, within eighteen months of each other, that it was time.
The story of why this happened now, and not in 1999 or 2012 or 2019, is actually interesting, and it has almost nothing to do with blockchain or AI being "hot." The reason is more specific, and more surprising.
The 29-year nap, told accurately
The why behind the dormancy is more interesting than the number.
The obstacle was never technical. It was human.
The first serious attempt to make tiny online payments a real thing was DigiCash, David Chaum's electronic cash company. Chaum understood the problem (digital money, independent of banks, spendable online) better than almost anyone in the 1990s. DigiCash required users to install software, load a wallet, and consciously authorize each purchase. For all its cleverness, it asked people to think before every click. It filed for bankruptcy in 1998.
Then came Flattr (2010), which asked you to fund a monthly tip budget and distribute it across sites you visited. Elegant in theory; tiny in adoption.
Bitcoin looked like it might thread the needle. The amounts were small enough to feel costless, wallets were improving, and the UX was close enough to "just send it." Then Bitcoin became a speculative asset and the micropayment use case got trampled by the investment potential.
The pattern across three decades: every attempt hit the same wall. Call it the consent friction problem. The question every micropayment system has to answer is: will a person consciously approve a sub-dollar payment, before receiving the thing they're paying for, fast enough that the experience feels acceptable?
The answer, every single time, was no. Not consistently, not at scale.
Humans have a revealed preference: they would rather give their credit card number once, subscribe to something monthly, and receive unlimited access (even if that means overpaying) than stop and approve tiny transactions on demand. The paywalled web, Spotify, Netflix: all of them are elaborate workarounds for the fact that per-request payment has never worked for human users.
So HTTP 402 sat. Not because nobody tried. Because the entity that needed to do the paying was always a human, and humans have friction.
What actually changed
Two things shifted between 2024 and 2026. Neither made enough noise.
The first was unit economics. Before Layer-2 chains, making a payment on Ethereum cost roughly $0.30 in gas fees. That made per-request pricing economically ridiculous for anything under a few dollars. On Base today, the same payment costs less than half a cent. Stablecoins solved the asset volatility problem, while Layer-2s solved the fee bottleneck. The combination meant, for the first time, that charging $0.005 per API call was not a rounding error on both sides.
The second change is the one that matters more, and it is the one that reframes everything: the client changed.
AI agents, software that calls external APIs autonomously, without a human in the approval loop for each request, started running at real scale in 2024 and 2025. And agents have a property humans never had: they can authorise payments pre-emptively, within a policy, without pausing.
You give an agent a budget of $5. You tell it to call whatever endpoints it needs to complete the task. The agent handles the payment on each 402 response automatically, within the cap you set.
This dissolves the 29-year problem entirely. Every failed micropayment system assumed a human in the loop. Every human-in-the-loop system hit consent friction. The question was never "can we build a payment protocol". We had those. The question was "can we get a human to approve a tiny payment fast enough that they don't resend it?" And the answer was always no.
The agent removes the human from the loop. The problem that stopped 402 from working was not a protocol problem. It was an interface problem. The agent turns out to be the interface 402 was written for. The client that doesn't flinch at a $0.01 authorization.
A few protocols, all in production
In the space of about six months — October 2025 to March 2026 — many protocols shipped that all do roughly the same thing. They are not compatible with each other. They are also not interchangeable: each makes different tradeoffs that make it the right call for a different context. Here are four examples:
x402
Coinbase launched x402 in October 2025, with V2 following in December. The wire format is JSON: the server returns a 402 with a header that carries the required amount in USDC, the payee's address, the chain, and a nonce. The client constructs an EIP-3009 transferWithAuthorization signature, a meta-transaction that pre authorises a specific transfer without broadcasting anything to the chain, and includes it in the retry header. Coinbase's facilitator verifies the signature and settles the transfer on Base before handing the response back to the origin server.
The numbers that came out in early 2026 were large. As of April, approximately 69,000 active agents have processed over 165 million transactions totalling $50 million in volume, with nearly half a million payments in a single peak week. The x402 Foundation now includes Visa, Google, AWS, Anthropic, Circle, Cloudflare, and Vercel. Cloudflare has support built into their infrastructure products. This is not a whitepaper.
The practical running system depends on Coinbase' facilitator. That is an operational convenience, and it is also a centralisation point, something the Coindesk reporting from March 2026 called out directly. Demand for decentralised alternatives exists.
L402
This is the one that the agent payments community almost never talks about, which is strange because it predates x402 by five years.
Lightning Labs introduced the protocol in 2020, initially as LSAT (Lightning Service Authentication Token), renamed L402 in 2024. The mechanism: the server returns a 402 with a WWW-Authenticate: L402 header carrying two things: a macaroon (a structured, delegatable credential that can encode caveats about scope, time, and spending limits) and a BOLT-11 Lightning invoice. The client pays the invoice over the Lightning Network, receives a 128-bit payment preimage as proof, and re-sends the request with Authorization: L402 <macaroon>:<preimage_hex>.
The preimage is the interesting part. It is cryptographic proof that the Lightning payment settled. The payment is unforgeable, tied to that specific invoice, verifiable locally without any chain lookup. For applications where auditability matters, this is cleaner than reading transaction data off a blockchain.
The granularity is also striking: 1 satoshi is roughly $0.0007 at current prices. You can price an API call at a fraction of a cent and have the maths work cleanly.
The honest limitation is operational. Running a Lightning node is real work. Channel liquidity, peer selection, uptime — not insurmountable, but not nothing either. Most AI startups will not spin up an LND instance for this. L402 is technically elegant and, for now, aimed at an audience that has already decided Lightning is worth the operational cost.
Stripe MPP-SPT
Stripe's Shared Payment Token, launched in March 2026, deserves a small caveat up front: it is not quite an HTTP 402 protocol in the same way as x402 and L402.
An SPT is a payment credential issued by a user (or by an agent on the user's behalf) that is scoped to a specific merchant, capped at a specific amount, and set to expire within minutes. When the agent presents the token at checkout, the merchant redeems it via a standard Stripe PaymentIntent. The underlying payment method — credit card, bank account, BNPL — never leaves the user's wallet. The card number is never shared with the merchant. Stripe
mediates the transfer.
The 402 pattern fits on top: the server can return a 402 with SPT requirements; the client mints a token with the appropriate scope and retries. But the architecture underneath is card networks and Stripe infrastructure, not a blockchain signature or a Lightning preimage.
This is exactly what makes it interesting for a different audience. A finance team that wants AI agents to spend company money on approved suppliers, with hard spending caps, merchant restrictions, and short expiry windows, does not want stablecoins. They want a credential tied to a payment method they already control, which they can revoke from a dashboard if something
goes wrong.
MPP-Tempo
The newest of the four, also shipping in March 2026, is MPP-Tempo: a stablecoin payment rail on a chain built specifically for machine-to-machine transactions.
Where x402 repurposed EIP-3009 from general-purpose Ethereum, and L402 repurposed BOLT-11 from Lightning, Tempo built its transaction format (EIP-2718 type 0x76) from scratch with per-request economics in mind. The MPP shared helper layer, a common header format that both Tempo and SPT use, sits on top and makes the 402 challenge/retry flow consistent regardless of
which backing rail is active.
The interface is the standard; the rail is the implementation
Read the protocol wars coverage (AP2 vs. ACP vs. x402 vs. MPP, the fragmented standards landscape, the thirty-plus competing proposals) and you might conclude that choosing any of these today is a bet you will probably lose.
That's partially right. What I think is more useful is to notice what all four of them share.
Every 402 system uses the same HTTP idiom: the server issues a challenge, the client returns proof. The challenge format differs, e.g. JSON headers, macaroon-plus-invoice pairs, SPT requirements, Tempo transaction descriptors. The proof format differs, e.g. EIP-3009 signatures, Lightning preimages, Stripe tokens, Tempo transactions. But the HTTP structure is identical: 402 Payment Required on the first request, a credential in the Authorization header on the retry, 200 OK on success.
This is not a coincidence. It is the WWW-Authenticate / Authorization challenge-response pattern. It's the same one that has handled API authentication since the late 1990s. The machine-to-machine payment problem, once you strip
away its cryptocurrency context, turns out to be a variant of an authentication problem where the credential is proof of payment rather than proof of identity. The primitives that handle auth for every API you have ever built also handle payment, if the client knows how to generate the right header.
This reframes the question of which rail to use. The interface, i.e. HTTP 402, a structured challenge, a retry with a proof credential, is already converging. The rails are competing implementations of the same interface. An implementations can be swapped out. A client that speaks the 402 challenge pattern can learn a new rail without breaking. (Full disclosure: this is the exact bet I made when I built Routeweiler, a Python library that handles the four rails behind a single HTTP surface. I mention it because it highlights the concept clearly, i.e. we can successfully separate how a payment looks from how it actually processes. No intention to prompt anyone reading this to install it.)
I am not confident which rail will dominate five years from now. Possibly all four survive in different verticals: x402 for crypto-native data APIs, L402 for Lightning-native services, SPT for mainstream retail and enterprise procurement, Tempo for high-throughput machine applications with purpose-built economics. Possibly one absorbs the others, or a fifth protocol nobody has written yet wins the whole thing.
What I feel more confident about is that HTTP 402 itself is now load-bearing for the first time. In 2030, developers will look at agent logs, see 402 → 200, and think nothing of it, the same way nobody today thinks about the TCP handshake that preceded every web page they have ever loaded.
The status code that spent 29 years as a placeholder for a future nobody finally has its moment. The missing piece was never the protocol. It was a client that doesn't flinch at a $0.005 charge before it checks out.
*One footnote: implementing adapters for all four of these got repetitive quickly. Routeweiler is an open-source Python client that handles them behind a single
await client.get(url). Worth a look if you want to skip writing the EIP-3009 signing yourself.
