The account was the hard part

Give an agent a real task and watch where it stops.

“Find me the best transcription service for these call recordings.” It reads comparisons, pulls up pricing pages, shortlists five providers, and then hits a wall that has nothing to do with intelligence. Create an account. Confirm an email. Enter a card. Pick a plan. Generate an API key. Paste the key somewhere it can reach.

Every one of those steps assumes a person. Not a smart person, just a present one, with an inbox, a card, and a hand on a mouse. The agent isn’t blocked because the task is hard. It’s blocked because the web’s front door only opens for humans.

The usual framing for what Cloudflare shipped on August 4th is “AI agents get a wallet.” That framing is too small. The wallet is the easy half. The hard half is the account.

What an account really is#

An account looks like one thing and is actually three, welded together:

• Identity. Who is this, across sessions, so we can rate-limit them, ban them, support them.
• Entitlement. What is this identity allowed to call, at what quota, on what plan.
• Billing. How we get paid, on a monthly cycle, from a payment instrument on file.

Fusing those three made sense for people. A human relationship with a service is long-lived, so a long-lived object to hang it on is the right shape. You sign up once and use it for years. The monthly cycle amortizes the setup cost.

None of that holds for an agent evaluating five transcription APIs for ninety seconds each. It wants a relationship that lasts one request. Creating a durable, three-part object to buy two cents of transcription is absurd overhead, and it’s exactly the overhead that stops the agent cold.

So the interesting move isn’t handing the agent a card. It’s unbundling the account back into its three parts and making each one work per-request. x402 does billing. Cloudflare Wallets does the money and the limits behind it. cloudflare.pay does identity. That’s why these three pieces keep being announced together: they’re not three features, they’re one account taken apart.

Billing: what 402 actually does on the wire#

HTTP has had a 402 status code since the early spec drafts. RFC 9110 still lists it as “reserved for future use,” which is a polite way of saying nobody ever agreed on what to put in the response. It sat there for thirty years as a placeholder for a payments layer that never arrived.

x402 is the attempt to fill it in. It started at Coinbase and is now governed through the x402 Foundation under the Linux Foundation. Version 2 landed in December 2025.

The flow is four HTTP messages and one signature. Worth walking through properly, because the hand-wavy version (“the agent just pays”) hides the parts that matter.

1. The agent asks for something. Ordinary GET, no payment attached.

2. The server quotes a price. It answers 402 with a JSON body describing what it will accept:

{
  "x402Version": 2,
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "amount": "10000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USDC", "version": "2" }
    }
  ]
}

Note that accepts is an array. The server can quote several ways to pay, and the agent picks one. amount is in atomic token units, so 10000 is one cent of USDC. This is a machine-readable price tag, which is the part the web never had. Prices have always lived in HTML for humans to read, or in a PDF a salesperson emails you.

3. The agent signs an authorization and retries. Not a transaction, a signature. On EVM chains the “exact” scheme uses EIP-3009 transferWithAuthorization, so the agent signs an object saying this exact amount, to this exact address, valid between these two timestamps, with this nonce:

{
  "signature": "0x2d6a7588d6acca505cbf0d9a4...",
  "authorization": {
    "from":  "0x857b06519E91e3A54538791bDbb0E22373e36b66",
    "to":    "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
    "value": "10000",
    "validAfter":  "1740672089",
    "validBefore": "1740672154",
    "nonce": "0xf3746613c2d920b5fdabc0856f2aeb2d4f88ee60..."
  }
}

That goes back on the retry in a header. The agent never broadcasts anything and never holds gas.

4. The server verifies, settles, and answers. It hands the signed payload to a facilitator, which exposes /verify (is this signature good and funded) and /settle (put it on chain). The facilitator pays the gas and broadcasts, but it’s bound by the signature: it cannot change the amount or the destination, only decide whether to relay it. Then the server returns the actual resource.

The design decision I find genuinely clever is that last one. The agent’s side of a payment is a local signing operation. No wallet popup, no gas balance, no chain-specific plumbing, no round trip to a payment processor’s dashboard. If you have ever wired up Stripe, the difference in ceremony is the whole point.

The scale claim is worth reading with the usual caution about self-reported numbers, but x402.org’s dashboard puts the last 30 days at about 75 million transactions against $24 million of volume. Divide those and the average payment is roughly 32 cents. Whatever else is true, these really are micropayments.

Money: what Cloudflare Wallets adds#

A protocol for paying is not the same as having money to pay with. Cloudflare Wallets is the second piece: stablecoin balances with a delegation model on top.

There are two kinds. An Account Wallet belongs to a human or a company. You fund it, and you can pull funds back out. A Virtual Wallet belongs to an agent, is addressed by an API key, and can only spend inside limits the Account Wallet owner sets: a cap, an allowlist of where it can spend, a maximum size for any single payment, and an escalation path when the agent wants to exceed them.

Cloudflare makes one observation in that post that I think is the most useful idea in the whole announcement, and it runs against intuition:

If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000.

A small budget buys the agent more freedom, not less. This is the same trade as a sandbox. You don’t make an untrusted process safe by reviewing every syscall it makes, you make it safe by bounding what it can reach and then letting it run unsupervised. A $10 cap is a blast radius, and once the blast radius is small enough, the human approval step stops being worth its own latency. The alternative, an agent that must ask before every two-cent call, is not an autonomous agent. It is a very slow form of you.

Identity: what cloudflare.pay adds#

The third piece is a handle. Agents can optionally claim a readable name under cloudflare.pay, something like research.example.cloudflare.pay, that resolves to a Cloudflare account.

This is the identity third of the account, unbundled. A server receiving an x402 payment gets a wallet address, which tells it nothing except that money arrived. A handle lets it know the caller is acting for a particular organization, which is what it needs for the things identity is actually for: reputation, abuse handling, tiered pricing, and knowing who to talk to when something goes wrong.

The word optional is doing real work there. An agent can pay anonymously. That’s a deliberate design choice, and it means services get to decide whether they price anonymous traffic differently from identified traffic. I’d expect that gap to become the interesting number.

Cloudflare is building both sides of the market#

The wallet gets the attention, but the selling side arrived first, and it’s the reason Cloudflare is positioned here at all.

Pay Per Crawl let publishers charge AI crawlers for content. The Monetization Gateway, on a waitlist since July, generalizes that: pricing rules for any resource behind Cloudflare, expressed the same way you’d write a WAF rule. A cent per GET to /api/premium/*. Variable pricing when the work is variable, up to two dollars for an image generation. Intercepting a 401 and returning payment requirements instead of a login wall, which is exactly the unbundling described above, implemented as a rule. Alongside it, Web Bot Auth does cryptographic agent identity, so a merchant can require identified and paid rather than just paid.

Settlement is in USDC and Open USD, under a second, at fees small enough that a one cent charge isn’t absurd.

Put it together and Cloudflare is running the buyer side, the seller side, the identity layer, and the network in the middle. That’s a strong position, and it’s fair to say out loud that it’s also a lot of the agentic web’s plumbing sitting behind one company.

Where the demo breaks#

The transcription story is a good story. It is also doing a lot of work to hide four unsolved problems.

Discovery is a ranking problem, and ranking problems get gamed. For the agent to try five services, it has to find five services. Coinbase ships x402 Bazaar, an index with a /list endpoint that agents can query by intent. It works. It’s also a search engine whose users are software with money, which is about as adversarial as a ranking surface can get. A recent paper by Li, Wang and Wang, Five Attacks on x402, names this directly: metadata gaming and Sybil flooding to get an agent to pick your endpoint before a single payment happens. SEO spam was annoying. SEO spam where the click costs money is a business model.

Paying to try is not the same as knowing which is best. “It spends a few cents testing them and compares quality” is the sentence the whole scenario rests on, and it’s the one nobody has solved. For transcription you can get somewhere with word error rate against a reference, if you have a reference. For most services you don’t have a ground truth, and the agent falls back to an LLM judging output quality, which is a well-documented way to reliably pick the answer that looks best. The payment rail removes the signup friction. It doesn’t hand you an evaluation harness, and the evaluation harness is the actual hard part of “find the best X.”

The security model is young. The same paper lists four more failures, and they are ordinary web bugs rather than exotic cryptography: releasing the resource before the payment has enough confirmations, so a reorg takes the money back while the response stands; a third party front-running settlement to burn the nonce; no per-request deduplication, so one payment gets replayed into many grants; and paid responses landing in a cache that isn’t payment-aware, leaking to clients who never paid. All of those are fixable and the authors propose fixes. None of them are fixed by adopting the protocol. Anyone putting this in front of real money should read that paper before the marketing.

Prompt injection stops being about data. This is the one I’d worry about most. Today a successful injection exfiltrates something. Against an agent holding a funded wallet, it moves money: a malicious 402 response that quotes an inflated price, or names an attacker’s payTo, or loops so the agent pays over and over. The spending caps are a real mitigation here, which is why the “$10 buys more freedom” framing matters. But a cap bounds the loss, it doesn’t prevent the attack, and an agent that pays attackers 100% of the time up to its cap is still a broken agent.

What it changes if it works#

The end state worth thinking about isn’t “AI can buy things.” It’s that the subscription stops being the default shape of software.

Seats and monthly plans exist because acquiring a customer is expensive and billing them repeatedly is cheap. That math only holds when the customer is a person who had to be convinced. When the customer is a process that decided to call you 400ms ago and may never call again, per-request pricing isn’t a downgrade, it’s the only pricing that describes what happened. APIs stop competing on plan tiers and start competing on price and quality per call, continuously, against whoever else is in the index. That is much better for buyers and much harsher for sellers with mediocre products and good sales teams.

It also means software gets built for a customer that reads docs instead of landing pages. A machine-readable price is a strange thing to design for after twenty years of optimizing pricing pages for hesitation.

It’s worth being clear about what exists right now, because the announcements read as more finished than they are. You can claim a cloudflare.pay handle today. Funding, Virtual Wallets, and actually paying for things are announced, not shipped. The Monetization Gateway is a waitlist. x402 itself is real and running at volume, but mostly among people who already had wallets. And it isn’t the only proposal: Google’s AP2 covers mandates and authorization without being a rail at all, and Stripe and OpenAI’s ACP handles merchant checkout. Those three are answers to different questions that all involve agents and money, and they will probably coexist rather than one winning.

So: not a finished system. But the shape is right, and the shape is the part I keep coming back to.

The web didn’t lack a payment button. It lacked a way to be a customer without first agreeing to be a person.