x402 and Machine Payments in 2026: Charging AI Agents per Request, and How Much of It Is Real

HTTP has had a status code for this since the early days of the web. RFC 9110 still says it plainly: "The 402 (Payment Required) status code is reserved for future use." In 2026 two protocols are trying to make that future arrive. x402, started by Coinbase and now run by a Linux Foundation project, answers a request with a price and accepts a signed stablecoin payment on the retry. The Machine Payments Protocol (MPP), from Stripe and Tempo, does the same through HTTP's authentication headers and carries cards as well as stablecoins. AWS and Cloudflare now sell both ideas at the edge, so a publisher can charge AI crawlers without touching its origin.
The pitch is attractive to anyone who sells data, an API or content that AI agents read: charge per call, settle in seconds, no accounts and no invoices. The numbers behind the pitch are another matter. An independent measurement of x402 on Base found that most recorded settlements are self-payments or money moving inside one cluster of wallets, and a blockchain analytics firm put the volume that looks like agents buying at roughly USD 5,000 to 11,000 a month in 2026.
This article is for owners and developers of APIs, data services and content sites deciding whether to charge agents now. It covers how the protocols work, what each provider offers as of 22 October 2026, what you would build, what the volumes really show, and the regulatory questions that come with holding stablecoins.
How x402 Works
The specification is at version 2, dated 9 December 2025, in a repository that moved from Coinbase to the x402 Foundation. It defines three roles: a resource server that wants payment, a client (often an agent) that pays, and a facilitator that "handles payment verification and blockchain settlement".
A paid request runs like this:
- The client asks for the resource and gets
402 Payment Required. APAYMENT-REQUIREDheader carries a Base64-encoded object listing one or more acceptable ways to pay, each with ascheme, anetworkin CAIP-2 form (eip155:8453is Base), anamountin the token's smallest units, anasset, apayToaddress and amaxTimeoutSeconds. - The client signs a payment and repeats the request with a
PAYMENT-SIGNATUREheader. On EVM chains that is an EIP-712 signature over an EIP-3009 transfer authorisation with a time window and a 32-byte nonce against replay. - The server has the facilitator verify the signature (
POST /verify, which "MUST NOT commit payment state"), runs its handler, then has the facilitator settle (POST /settle). - The server answers with the resource and a
PAYMENT-RESPONSEheader holding the transaction hash.
That is the default "authorization" flow: "the payment is verified before the resource executes and settled afterward". Two other flows are defined, one that settles first and one that takes a deposit and settles the final amount after. If a settlement was broadcast but not confirmed, the facilitator can return settlement_pending with the hash, and the server should reconcile before anyone retries.
Two details catch people out. Version 1, which most older tutorials show, used X-PAYMENT and X-PAYMENT-RESPONSE and network names such as base-sepolia; version 2 renamed the headers and moved to CAIP-2. And the same messages are defined over MCP and the Agent-to-Agent (A2A) protocol: over MCP, a paid tool returns a result with isError: true and the payment travels in _meta["x402/payment"].
The Four Payment Schemes
| Scheme | What it does | Where it is bound in the spec | Refunds |
|---|---|---|---|
exact | A fixed amount the server knows in advance | 18 networks, from EVM and Solana to Stellar, TON and XRPL | None defined: "any remedy is the resource server's own arrangement" |
upto | Authorises a maximum, charges actual use at settlement (for example per generated token) | EVM and Solana | None defined |
batch-settlement | Accepts a commitment per request and settles many later in one go, for when "gas fees exceed the value of individual requests" | EVM, Solana and a Cloudflare binding | Depends on the binding |
auth-capture | Hold, capture for less, void, refund, and a client reclaim after a deadline | EVM only; a draft (v1.1, 18 August 2026) | The only scheme that has them |
On EVM chains any ERC-20 token works in principle, through EIP-3009 (USDC's method) or Permit2. In practice the reference SDKs price in dollars and map "$0.01" to a USD stablecoin per network: USDC on Base and most EVM chains, several stablecoins on Solana, USDT on TON. The reference client accepts only assets it recognises and caps each payment at USD 1 by default. There is no euro default.
Facilitators: Who Moves the Money
The facilitator is "optional but recommended". It checks signatures and submits the onchain transfer, and the documentation says it "does not hold funds or act as a custodian": the money lands in your payTo wallet.
- The public
x402.orgfacilitator is for testnets only. The seller quickstart is explicit: "Do not reusehttps://x402.org/facilitatorfor mainnet routes." - Coinbase's hosted CDP facilitator charges nothing for the first 1,000 onchain transactions a month, then USD 0.001 each, with verification always free. It runs OFAC and Know Your Transaction checks on every payment, needs a CDP API key, and supports Base, Polygon, Arbitrum, Monad, World and Solana. It does not list
auth-capture. Batch settlement spreads the fee: "one onchain transaction can process thousands of payments". - The foundation lists other production facilitators, including Fireblocks, Polygon, PayAI, Corbits, Stellar and Celo, and says the list is "not an exhaustive catalog".
- You can self-facilitate, paying gas and, on Solana, building the duplicate-settlement detection a facilitator would otherwise provide.
The x402 Foundation became operational on 14 July 2026 with 40 members. Its premier members include Adyen, AWS, American Express, Cloudflare, Coinbase, Google, Mastercard, Shopify, Stripe and Visa; its technical steering committee has members from Coinbase, Cloudflare and Stripe. Membership is support for the governance, not a deployment. The launch release mentions "support for payment types ranging from traditional cards to stablecoins", but the specification has no card binding today.
Stripe's Machine Payments Protocol and Tempo
Stripe and Tempo launched MPP on 18 March 2026, the day Tempo's mainnet went live. It uses HTTP's authentication framework: a 402 with a WWW-Authenticate: Payment challenge, a credential in Authorization: Payment, and a Payment-Receipt header on success. Its intents are charge (one payment), session (streaming payment over a channel) and subscription, and its production payment methods are Tempo stablecoins and Stripe's card methods. Visa published a card specification and SDK for MPP the same day. The IETF document behind it is an individual Internet-Draft which "has no formal standing in the IETF standards process".
On Stripe, MPP accepts cards (through Shared Payment Tokens) and stablecoins, and Stripe also takes x402 stablecoin payments on Base, settled through Coinbase's facilitator into a Stripe deposit address. Either way the result lands in your Stripe balance as a PaymentIntent, and stablecoins sent to a deposit address are converted: "Stripe automatically offramps these payments and settles them into your Stripe balance." The conditions:
- Stablecoin acceptance is "available to businesses in all US states, except New York". Elsewhere you email Stripe to request access, which is reviewed; the EU, Hong Kong, Mexico and Switzerland are in private preview.
- Minimums are USD 0.50 for a card payment and 0.01 USDC for a stablecoin payment. MPP sessions can charge in steps "as small as 0.000001 USDC" but settle in whole cents, and a sub-cent remainder is forfeited.
- Stablecoin payments on Stripe have no dispute support, refunds go back as stablecoins to the original wallet, and a single transaction is capped at USD 10,000.
- The APIs are preview versions (
2026-07-29.previewfor MPP,2026-05-27.previewfor the x402 deposit address).
Visa's Intelligent Commerce Connect, announced on 8 April 2026 as a pilot, lists MPP among the agent protocols merchants can accept through it. It does not list x402.
Charging at the Edge: AWS and Cloudflare
If your content or API already sits behind a CDN, the edge can do the charging.
AWS WAF AI traffic monetization (announced 15 June 2026) returns "a machine-readable HTTP 402 Payment Required response using the x402 open protocol" to bots and agents, and settles through Coinbase's facilitator into a USDC wallet you provide on Base or Solana. The feature has no extra charge, but normal WAF and Bot Control fees apply, and it works only with CloudFront. You can price verified search crawlers differently from unverified agents and training crawlers, and test before going live. It settles only when your origin returns a 2xx, and does not charge for 4xx or 5xx. The documentation is frank about the costs: a minimum of USD 0.001 per request, "several seconds of additional latency" on paid requests, bot detection that is "probabilistic", and a warning that a Monetize rule not limited to bots "will effectively block access for non-automated clients". "AWS is not a party to or in the flow of funds", and you agree to Coinbase's terms. Stripe settlement and MPP support were "coming soon" on the announcement.
Cloudflare pay per crawl is a different model. It is in closed beta, your domain must be on Cloudflare, you set one price for all crawlers you charge, and Cloudflare "acts as the Merchant of Record". Crawlers identify themselves with Web Bot Auth and pay by Stripe invoice, not from a wallet. You never touch stablecoins.
Cloudflare Workers can put an x402 or MPP proxy in front of any HTTP backend, priced per route pattern, and can charge only requests with a low bot score so people browse free. The Agents SDK has paidTool, which turns an MCP tool into a paid one. Note that Cloudflare's examples use the testnet-oriented x402.org facilitator and version 1 network names; for production, swap in a production facilitator and CAIP-2 identifiers.
How Much of It Is Real
The headline numbers are large and do not agree with each other. The x402.org home page shows 75.41 million transactions and USD 24.24 million in the last 30 days, with no date, source or method on the page. Coinbase says its facilitator has processed "more than 100 million transactions and $28 million in payment volume across Base and Solana alone", with no period. These are counts of settlements, and that is the problem.
A measurement study from researchers at City University of Hong Kong, The Chinese University of Hong Kong and Zhejiang University (a preprint, posted 14 July 2026) looked at 280 days of x402 on Base, from 17 September 2025 to 23 June 2026: 136,708,672 settlements worth USD 44.1 million. Of those, "21.20% are fictitious and 63.78% internal settlement within a linked cluster". The value that "demonstrably reaches a nameable service" was USD 187,861.35. Of 624 recipients that were ever paid, 249 earned at least USD 10, the median lifetime revenue was USD 3.96, and only 474 of 910 advertised hosts still returned a live payment challenge. The authors' conclusion: "Settlement count measures manufacturability, not adoption."
TRM Labs, which sells blockchain monitoring, counted USD 52.7 million across 198.9 million settlements on Base, Solana and Polygon since May 2025. About half fell away after removing self-payment, bulk flows and thin-buyer sellers. Of the USD 25.62 million left, it estimated that between 0.6% and 7.5% "appears to be agentic", and that the volume agents moved stayed at roughly USD 5,000 to 11,000 a month through 2026. Its reading for sellers is useful: "attracting agent traffic takes a different design. It needs to be machine-readable and have per-call pricing on an endpoint a buyer can discover without a human ever seeing the page."
None of this says the idea is wrong. It says that in October 2026 an endpoint charging agents per call should expect revenue in the range of an experiment, and should not plan around the headline counts.
Who Holds the Money, and Which Rules Apply
With x402 the payment goes straight to your wallet. That means your business holds the keys, carries USDC on its books, and converts it to its own currency, unless a provider such as Stripe converts it for you. The facilitator's screening (Coinbase's OFAC and KYT checks) is something the facilitator does; the x402 specification defines none. Refunds are yours to arrange: exact "defines no refund", and Stripe's stablecoin payments have no disputes.
Two regimes are relevant to whoever sits in the flow of funds.
- United States: the GENIUS Act. Public Law 119-27, approved on 18 July 2025, takes effect 18 months after enactment or 120 days after final regulations, whichever comes first. Treasury's proposed rule of 18 August 2026 says the effective date "is expected to be January 18, 2027". From that date, a digital asset service provider may not make a foreign issuer's stablecoin available in the US unless the issuer can comply with lawful orders. From 18 July 2028, a digital asset service provider may not offer or sell a payment stablecoin to a person in the US unless a permitted issuer issued it. The statute defines a digital asset service provider by activities such as exchanging, transferring or holding digital assets for others, done "for compensation or profit".
- European Union: MiCA. The transitional period for crypto-asset service providers ended on 1 July 2026. ESMA's statement: "any entity providing crypto-asset services to EU clients without a MiCA licence will be in breach of EU law and must cease offering such services", and non-EU firms may not serve EU clients, "also ... in a business-to-business context". USD stablecoins are e-money tokens under MiCA. ESMA's advice to users is to check that a provider is on its interim register.
What none of these sources settles is the position of a business that only receives stablecoins as payment for its own API or content. The GENIUS Act's restrictions are written for digital asset service providers, and MiCA for crypto-asset service providers; whether your arrangement makes you either, or depends on providers who must be, is a question for counsel in each jurisdiction where you operate. We are engineers, not lawyers, and we build to the answer your adviser gives. In practice, ask each provider in your chain whether it is licensed where your customers are.
Four Ways to Build It
From least code to most:
- Let the CDN charge. AWS WAF on CloudFront: a monetization config with your wallet and prices, Monetize rules scoped to bot labels, test mode first, no origin changes. Cloudflare pay per crawl: if you are in the beta, a price and payout settings, with Cloudflare as merchant of record.
- Let a payment provider charge. Stripe MPP: a Stripe profile, the
mppxlibrary, achargecall in your handler and a Tempo deposit address. Card and stablecoin, settled in fiat to your Stripe balance. Or x402 on Stripe with a CDP account and a Base deposit address, stablecoin only. - Run x402 in your own server with the SDK middleware for your framework (Express, Hono, Next.js, Fastify; Python and Go SDKs exist), a hosted facilitator, and a route config of scheme, price, network,
payToand description. - Self-facilitate, if you need full control or a network nobody serves.
Whichever route you take, some decisions stay with you: which scheme fits the work (exact for fixed prices, upto for metered work, batch settlement when calls are worth less than gas), who sees the paywall (a 402 shown to a browser user is a dead end), how you reconcile settlement_pending, idempotent retries if clients send a payment identifier, refunds, custody of the receiving wallet, and how you book USDC receipts. The agents also have to be able to pay: an x402 client needs a wallet holding the right stablecoin on the right network, an MPP client a Link or Tempo wallet, a pay per crawl crawler a Web Bot Auth identity and a Stripe billing relationship. You cannot assume any given agent has any of these.
Should You Charge Agents Now?
- You sell an API or data that agents already call: an experiment is cheap. Put one or two endpoints behind MPP or x402 alongside your existing keys and plans, price above the floors (USD 0.001 at AWS, 0.01 USDC on Stripe), and measure who pays. Keep the existing paid plans: the agent-payment channel will be small for now.
- You publish content and AI crawlers already read it: the edge options exist for this. AWS WAF if you are on CloudFront and comfortable holding USDC; Cloudflare pay per crawl if you are on Cloudflare, want card settlement and can get into the beta. Neither is a revenue plan yet; both give you a price and a log of who refused to pay it.
- You want agents to buy goods from your shop: this is not that problem. Card networks, Stripe's Shared Payment Tokens and Google's and OpenAI's checkout protocols cover agents buying from merchants, and we cover them in our article on agentic payments.
What Could Change
- The GENIUS Act's start on 18 January 2027 (earlier if final rules land first), and the 2028 restriction after it.
- AWS adding Stripe and MPP settlement, announced as coming soon.
auth-capturematuring, which would give x402 refunds outside drafts.- MPP's Internet-Draft moving, or not, towards an IETF working group.
- Visa's Intelligent Commerce Connect widening beyond its pilot partners, which would bring card-funded agent payments to more merchants through MPP.
Where to Get Help
We build the server side of paid machine access: metering and pricing per endpoint, x402 or MPP challenges in front of existing APIs and MCP tools, reconciliation of settlements into the systems your finance team already uses, and the bot identification that decides who sees a price. Our AI agent development and MCP integration service is where that work starts.
If you are weighing whether to charge agents for your API or content, and through which provider, write to office@c9group.dev.
Payments
New guides and rule changes by email
When a rule changes, a deadline moves or we publish a new guide, we send it by email.