An AI agent asks a server for a data feed, and the server answers with three digits that have sat unused in the HTTP spec since 1991: 402 Payment Required. That response is where both of this year’s machine-payment protocols meet, and where the card-versus-stablecoin argument gets decided.
Agents can analyse market data faster than any human, but the moment they need a premium feed or a sanctions screen, they stop and wait for a human to authorise payment. Card rails lose money below about a dollar, and API keys were never built for open commerce between machines. Two protocols now revive that dormant 402 code as a pay-per-request handshake: Coinbase’s x402, and Stripe and Tempo’s Machine Payments Protocol. x402 settles in USDC on stablecoin rails; MPP is rail-agnostic, reaching stablecoins, cards and Bitcoin’s Lightning Network. It’s the same shift we covered in what agentic commerce actually is, which sits inside the wider AI agent wallets and the agentic commerce landscape.
Here’s what each rail does, which use case it fits, and how to read the numbers honestly.
What is x402, and how does it let AI agents pay for resources?
x402 is Coinbase’s answer to HTTP 402 “Payment Required”, left undefined in RFC 9110 since the original 1991 spec. x402 fills that placeholder with a four-step handshake: the agent requests a resource, the server returns 402 with payment terms, the agent returns a signed USDC transfer authorisation, and the server verifies it and returns the resource. The spec lives at x402.org, and governance moved to the x402 Foundation under the Linux Foundation, with 40 member organisations including AWS, Circle, Cloudflare, Google, Mastercard, Stripe and Visa. Coinbase created it; it no longer controls it.
The agent never touches a blockchain transaction. A facilitator verifies the signed payload, an EIP-3009 or Permit2 authorisation, then broadcasts the USDC transfer on Base, Solana or Polygon and reports finality back. The agent just holds a funded wallet and signs a credential.
Ticket size drives the design. Coinbase reported 69,000 active agents and 165 million transactions by April 2026, roughly $50 million in volume, an average call near $0.30. Sub-cent gas on Base and Solana is what makes that viable; on card rails the interchange would swallow it first. That is the seed of micro commerce, and it sits inside the wider agentic commerce landscape.
x402 versus Stripe’s Machine Payments Protocol: which machine payment rail fits which use case?
x402 and MPP sit at different layers of the machine payment landscape, so the choice comes down to workload. x402 is a developer-first, per-request handshake: one signed USDC payment per call, settled on Base, Solana or Polygon through a facilitator. Stripe and Tempo’s Machine Payments Protocol is enterprise-first, formalising HTTP 402 with a WWW-Authenticate: Payment challenge and adding a session primitive, so an agent pre-authorises a spending limit once and streams many small payments through a long task without a transaction each time.
On settlement, x402 is stablecoin-only in practice; MPP is rail-agnostic, settling stablecoins on Tempo, its Layer 1 settlement network, reaching card rails through Visa, and running Bitcoin over Lightning via Lightspark, the Lightning infrastructure provider. On authorisation, x402 issues a single signed per-request credential, whereas MPP’s session works like OAuth for payments, aggregating thousands of micropayments into one settlement event. Stripe now accepts agent payments over MPP in stablecoins and fiat through cards, Klarna and Affirm. Both assume identity was handled upstream, by AP2 (the Agent Payments Protocol) mandates or Visa’s Trusted Agent Protocol.
So the verdict is per use case, and you can map it to your own workload. x402 fits single-shot micro commerce and API or inference calls; MPP fits metered, streaming workloads that need card reach or aggregated settlement inside regulated merchant flows. Developer-first and enterprise-first standards tend to stay separate, and the choice depends on how agents get identified across these rails.
Card rails versus stablecoin rails for agent payments: which wins?
There is no universal winner: the two rails are built for opposite ticket sizes. Card rails carry an interchange floor of roughly $0.30 to $0.50 per transaction, plus batch clearing on banking hours, which makes sub-dollar tickets impossible but keeps chargeback rights and merchant reach. Stablecoin rails settle in seconds with sub-cent gas, which makes a sub-dollar micro payment viable but leaves settlement irreversible: a refund is a new seller-originated transfer, not a reversal.
You can see the two bets in how the players have positioned themselves. Coinbase backs the bare protocol, pay-per-request on stablecoins. Cloudflare’s cloudflare.pay is a different answer to the same problem: an identity-plus-capped-spending wallet that stores stablecoins and settles through x402, with Virtual Wallets whose allowance, allow list and cap limit overspend. Those two are complementary. The card-native camp is the card networks themselves: Visa’s Trusted Agent Protocol signs agent identity into HTTP headers, and Mastercard’s Agent Pay for Machines promises permissioned settlement across cards and stablecoins.
The headline numbers deserve scrutiny. Chainalysis counted more than 100 million x402 transactions on Base through Q1 2026, but much of that was a pay-to-mint memecoin game, and an a16z partner put real on-chain agent volume near $1.6 million against a $24 million headline figure. MPP has processed roughly $200,000 since March, with average tickets between $0.05 and $0.30.
Which wallet spends on which rail is the next decision, covered in the wallets and credentials that spend on these rails and the on-chain data on real volume.
There is no winner in any of these debates, and that is the point. The card-versus-stablecoin choice and the x402-versus-MPP choice both turn on the same three things: ticket size, settlement finality and who owns the loss when a machine pays wrongly. If your tickets sit below a dollar, you inherit stablecoin economics; if you need chargebacks and merchant reach, you stay on card rails. The dormant 402 code now carries two competing semantics, so the choice your business faces is which rail economics you inherit, and which losses you accept along with them. For the plain-English map of how those choices fit together, see agentic commerce put simply.
Frequently Asked Questions
Is HTTP 402 a real status code, or something Coinbase invented?
HTTP 402 “Payment Required” is a genuine status code, not an invention. It has been reserved since the original 1991 HTTP specification and remains formally undefined in RFC 9110. It stayed dormant for decades because the web had no native way for a machine to pay. x402 and Stripe’s MPP simply give that dormant code defined semantics, turning it into a pay-per-request handshake.
Do AI agents need their own cryptocurrency wallet to pay through x402?
Yes, essentially. An agent needs a funded wallet holding USDC, and it signs a transfer authorisation to pay for each resource. It does not hand-roll a blockchain transaction itself. The x402 Facilitator verifies the signed payload, broadcasts the USDC transfer on Base, Solana or Polygon, and reports finality back to the server, so the agent only manages credentials rather than raw on-chain mechanics.
Does x402 only work with USDC, or can agents pay in other currencies?
In practice, USDC is the dominant settlement asset for x402 because it is a stable, widely accepted dollar token with deep liquidity on Base, Solana and Polygon. The protocol itself is not strictly limited to one token, but the design economics and observed volume centre on USDC. That focus is deliberate: a stable unit of account is what makes a roughly US$0.20 ticket predictable for both buyer and seller.
Who pays the transaction fee on an x402 payment, the buyer or the seller?
The buyer (the agent) effectively covers the network fee, though on Base and Solana those gas costs are sub-cent, which is precisely what makes pay-per-request viable. If the seller absorbed a card-style fee, a US$0.20 ticket would be loss-making. So the economics depend on cheap stablecoin gas rather than an interchange charge, and the facilitator handles the broadcast on the agent’s behalf.
What happens if an AI agent pays the wrong amount or the wrong recipient?
On a stablecoin rail, settlement is final, so a mistaken payment cannot simply be reversed. Recovery depends on the recipient choosing to send funds back, which becomes a new seller-originated transfer. This is why scoped credentials and spending caps matter. The liability question sits upstream, in whatever authorisation mandate or wallet policy let the agent spend in the first place, not in the protocol itself.
How do refunds work on a stablecoin rail after settlement?
They do not work the way card refunds do. Block-confirmation settlement on Base or Solana is irreversible, so a refund is not a reversal but a fresh transfer the seller initiates back to the buyer. There is no chargeback mechanism to force it. Card flows, by contrast, carry regulated dispute and chargeback rights, which is a real advantage for consumer-facing, dispute-sensitive purchases.
What is an x402 facilitator, and does every merchant need to run one?
A facilitator is the service that verifies a signed payment credential, simulates and broadcasts the USDC transfer, and reports settlement finality back to the server. It spares the payer from hand-rolling blockchain transactions. Not every merchant needs to operate one: a facilitator can be a third-party or shared service, so a seller can accept x402 payments without building its own on-chain infrastructure.
Can an AI agent use x402 to buy from a website that only accepts credit cards?
Not directly. x402 settles on stablecoin rails, so it cannot transact through a card-only checkout on its own. Reaching card-native merchants usually means the Stripe/Tempo MPP path, which is rail-agnostic and extends to card rails via Visa, or a card-native wallet such as cloudflare.pay. In short, x402 fits stablecoin-native sellers, while card acceptance depends on a different layer.
Where do I find the official x402 specification and documentation?
The official protocol documentation lives at x402.org. Governance is vendor-neutral and sits with the Linux Foundation’s x402 Foundation, which is notable because the protocol was originally created by Coinbase but is not controlled solely by it. For the competing standard, Stripe and Tempo’s Machine Payments Protocol is documented through the IETF draft-httpauth-payment work, where the 402 semantics are formalised.
Is Cloudflare’s cloudflare.pay a direct rival to Coinbase’s x402?
They compete for the same machine-payment use cases but sit on opposite rails. cloudflare.pay is a card-native, identity-plus-capped-spending wallet integrated with Visa’s Trusted Agent Protocol. x402 is the stablecoin-native, pay-per-request path settling USDC on Base, Solana or Polygon. Treat them as complementary bets divided by ticket size, not a two-horse race: cards for reach and dispute rights, stablecoins for sub-dollar machine commerce.
Is the reported boom in agent payments real volume or mostly hype?
Be sceptical of headline numbers. Chainalysis has counted 100M+ transactions on Base, which sounds enormous, but a16z estimated only around US$1.6M of genuine volume against roughly US$24M of headline volume, with much of the gap being memecoin-farming noise. The honest signal is observed volume and ticket size, not launch statistics, which is why this article measures rails against real economics.
Will card rails and stablecoin rails eventually merge into one system?
A full merge is unlikely, because the two are built for opposite ticket sizes. Cards carry a roughly US$0.30 to 0.50 interchange floor and batch clearing, which suits consumer retail and dispute-sensitive purchases but makes sub-dollar tickets impossible. Stablecoins settle in seconds with sub-cent gas, which suits machine-to-machine micro commerce. A rail-agnostic layer such as MPP may bridge them, but the underlying economics will keep them distinct.
