Cloudflare Wallets
The Programmable Wallet for the Agentic Internet

Every payment and identity primitive on the web assumes a human with a browser, an inbox, and a credit card. An agent has none of the three. That gap — not blockchain enthusiasm — is what Cloudflare Wallets is built to close.

Four assumptions agents break

Think about what it takes today for a piece of software to consume a paid API it has never used before. The path is so familiar it feels like nature rather than design:

1. Sign up. Which assumes an email inbox that can receive and act on a verification link.
2. Enter a card. Which assumes a payment instrument issued to a legal person.
3. Accept terms. Which assumes someone with the standing to consent on behalf of an entity.
4. Pick a tier. Which assumes the unit of consumption is a month, not a call.

An autonomous agent fails all four. It has no inbox, no card, no legal standing, and — most importantly — no interest in a month. It wants one request. It wants it now. And it may never come back.

The dormant status code

HTTP has had a reserved answer to this since 1997. Status code 402 Payment Required sat in the specification for nearly three decades with a single note attached: reserved for future use. It was the placeholder for a payments layer the web never grew.

The reason it never grew is not mysterious. Card rails have a floor. Interchange plus a fixed per-transaction fee — call it roughly thirty cents — makes a two-cent payment economically absurd. So the web routed around the problem with the only viable alternatives: advertising, subscriptions, and enterprise contracts. All three are human-shaped.

Two halves of one problem

It is worth separating the sides cleanly, because Cloudflare shipped them a month apart and they have very different maturity.

What this means if you run a platform with an API

Two wallet types, one delegation relationship. If you understand why the money and the authority to spend it live in different objects, you understand the whole product.

The two types

The delegation model is the design

The temptation is to read "Virtual Wallet" as "sub-account." It is closer to an IAM role with a budget attached.

The credential an agent holds is not the funds. It is a capability: you may spend up to X, with these counterparties, no single transaction above Y. The money never leaves the Account Wallet's custody until a transaction clears the guardrails. That separation is what makes the model safe enough to hand a key to a language model.

Where it sits in the stack

Four products, one network. The strategic point is adjacency: Cloudflare already terminates TLS for a large fraction of the web, so attaching a price to a request is a rule change, not a code change. No other participant in this race starts from that position.

The sizing that tells you what this is for

Cloudflare's own framing of budgets is the clearest signal about the intended use case. Their guidance is that an API "only costs a few cents to try," and that a ten-dollar budget is more than sufficient for an agent to go exploring.

Internalize the magnitude. These are not e-commerce payments with a checkout page. They are closer to metered compute — the mental model is an AWS line item, not a Stripe charge. That reframing changes how you think about everything downstream: budgets, alerting, reconciliation, and what an anomaly even looks like.

x402 is the part of this stack that is not Cloudflare's. It is an open specification, originated at Coinbase, that attaches a stablecoin payment to an ordinary HTTP request. Understanding it is what lets you build against the standard rather than the vendor.

The shape of the idea

No redirect. No checkout page. No session. A client asks for a resource; if payment is required, the server says so in the response it was already going to send, and the client retries with a signed authorization attached. The exchange lives entirely inside request and response headers.

On the wire

The three headers, base64-decoded. This is x402 version 2 — earlier drafts used X-PAYMENT and X-PAYMENT-RESPONSE, so treat header names as version-dependent and check x402.org before you write a client.

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "resource": {
    "url": "https://api.example.com/premium-data",
    "description": "Access to premium market data",
    "mimeType": "application/json"
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:84532",
      "amount": "10000",
      "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
      "payTo": "0x209693Bc6afc0C5328bA36FaF03C514EF312287C",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USDC", "version": "2" }
    }
  ]
}

Read that accepts array carefully — it is a list, and that is deliberate. A server can advertise several acceptable ways to be paid, and the client picks whichever chain and token it actually holds. Note also that amount is a string in the asset's smallest unit: "10000" against USDC's six decimals is one cent.

{
  "x402Version": 2,
  "resource": { "url": "...", "description": "...", "mimeType": "..." },
  "accepted": { /* the requirements entry the client chose */ },
  "payload": {
    "signature": "0x...",
    "authorization": {
      "from":        "0x...",
      "to":          "0x...",
      "value":       "10000",
      "validAfter":  "1740672089",
      "validBefore": "1740672154",
      "nonce":       "0x..."
    }
  }
}

Three details worth noticing, because they are the security model:

• value is fixed at signing time. The client authorizes exactly one cent. A server cannot decide to take more.
• validAfter / validBefore bound the window. Roughly a minute in this example. A captured signature is worthless after it expires.
• nonce prevents replay. The same authorization cannot be settled twice.

{
  "success":     true,
  "transaction": "0x1234567890abcdef...",
  "network":     "eip155:84532",
  "payer":       "0x857b06519E91e3A54538791bDbb0E22373e36b66"
}

// failure case
{
  "success":     false,
  "errorReason": "insufficient_funds",
  "transaction": "",
  "network":     "eip155:84532",
  "payer":       "0x857b06519E91e3A54538791bDbb0E22373e36b66"
}

The facilitator is the load-bearing abstraction

The single most important architectural decision in x402 is that the resource server never touches a blockchain. It calls /verify and /settle on a facilitator and gets back JSON. That is an ordinary HTTP dependency, the kind every backend team already knows how to reason about.

This is why the protocol is adoptable. Nobody has to run a node, manage gas, or hold a private key on a web server to sell something. Cloudflare's role in its own stack is exactly this: the facilitator, running at the edge, in front of infrastructure you already have.

The server side is middleware

app.use(paymentMiddleware({
  "GET /weather": {
    accepts: [ /* schemes and networks you'll take */ ],
    description: "Weather data",
  },
}));

That is the whole developer-facing surface for a seller: declare which routes cost what. Everything else — challenge generation, verification, settlement — is handled beneath. With Cloudflare's Monetization Gateway (Module 5) you do not even write this much; it becomes a rule.

Adoption, honestly

Do the division before you get excited. Roughly $600M annualized across ~150M transactions is an average ticket in the low single dollars, and a meaningful share of that volume is machine-to-machine traffic among a small number of heavy participants. The transaction count is the genuinely notable figure — it says the rail works at volume — but this is not yet evidence of a broad two-sided market.

The adoption signal that is unambiguous: Cloudflare and AWS both shipped x402 support at their edges within about two weeks of each other in July 2026. When two hyperscalers implement the same spec that fast, the spec is no longer speculative.

Payment answers "will you pay?" Identity answers "who are you?" They are separable, and Cloudflare deliberately separated them — then made the second one optional. That optionality is the most consequential policy decision in the whole announcement.

Starting point: Web Bot Auth

Before wallets, Cloudflare had already been working the bot-identity problem. Web Bot Auth lets an automated client sign its HTTP requests with a keypair, so an origin can cryptographically verify that a request really came from the crawler it claims to be — instead of maintaining brittle IP allowlists and parsing user-agent strings that anyone can forge.

It works. It also has a plain human problem:

ed25519:9f2a7c1e4b8d05a3f6c2e9b7d14a8f0c3e5b9d2a7f4c1e8b6d0a3f5c2e9b7d1

That is a perfectly good identity and a completely useless name. You cannot write a policy against it that a colleague will understand six months later. You cannot put it in a contract. You cannot look at an access log and know who you are looking at.

The handle

A cloudflare.pay handle maps a readable name onto that keypair:

research.example.cloudflare.pay

Cloudflare's own analogy is DNS, and it is the right one: DNS did not invent addressing, it made addressing nameable. Everything that followed — certificates, reputation, allow lists, brand — attached to the name, not the number.

Note the hierarchy, because it is doing real work. example.cloudflare.pay is the organization; research.example.cloudflare.pay is one agent inside it. That gives a seller two granularities of policy for free:

• Organization level — "anything under example.cloudflare.pay gets partner pricing."
• Agent level — "scraper.example.cloudflare.pay specifically is rate-limited to 10 rps."

Identity is optional — and that is the interesting part

An agent may declare its identity or stay anonymous. Merchants decide independently whether they require one. Cloudflare shipped the mechanism and pushed the policy to the edges.

That single choice creates a pricing and access surface that did not exist before:

The unresolved problems

Two criticisms surfaced immediately on announcement day, and both are legitimate.

This is the half that already works. If you take one operational action from this course, it is on this side of the market — because being a seller requires no wallet, no agent, and no waiting for general availability.

Lineage: Pay Per Crawl grew up

The Monetization Gateway is the descendant of Pay Per Crawl, Cloudflare's earlier project that let publishers charge AI crawlers for content access. That was a narrow, defensive product: bots are taking my articles, let me put a price on it.

The Gateway generalizes it into something offensive. The unit is no longer "an article a crawler wants." It is any resource behind Cloudflare:

Configuration: it is a rule, not a rewrite

Sellers set payment rules using expression syntax in the same family as Cloudflare's existing WAF and Transform rules, managed through the dashboard, the API, or Terraform. If your team already manages Cloudflare config as code, this lands in an existing review process rather than a new one.

Cloudflare's published examples show the range:

The 401 → 402 conversion is the on-ramp

This deserves more attention than it got. You have an endpoint that today returns 401 Unauthorized to anyone without a key. The Gateway can convert that rejection into a 402 carrying a price.

Which means: your existing authenticated path keeps working, unchanged, for every existing partner. Contracted callers with keys never see a 402. Everyone who would previously have bounced off a wall now sees a price instead. It is purely additive — no migration, no deprecation, no partner communication. For a platform with an established API and real contracts, this is the difference between "a quarter of work" and "a sprint."

Outcome pricing is the strategically novel one

"$0.99 per resolved support escalation, paid only when work succeeds" is not a micropayment. It is a different pricing philosophy that micropayment rails happen to enable: you are selling a result, not an API call. When settlement is cheap and instantaneous enough, you can afford to charge only for outcomes — which changes the risk allocation between buyer and seller, and is much harder to express in a monthly contract.

Settlement

• Assets: stablecoins — USDC and Open USD.
• Path: peer-to-peer, directly to the seller's wallet. Cloudflare verifies and enforces at the edge; it is not taking custody in the middle.
• Speed: targeting sub-second finality.
• Fees: the x402 protocol itself charges zero. Chain fees are negligible on the target networks. Cloudflare's own pricing for the Gateway is a separate question you should ask before you model revenue.

The list of things a seller does not build is the actual product: no payment infrastructure, no invoicing, no metering service, no dunning, no fraud stack, no PCI scope.

You are handing spending authority to a system that takes instructions from untrusted text. Prevention is the only control you get, because settlement is final. Design accordingly.

The three published guardrails

The manual override is the most important product detail

An agent that exceeds its limits can request a manual override from the Account Wallet owner.

It would be easy to skim past this. Do not. Without it, every limit is a cliff: the agent hits a wall, the task fails, and the human discovers it later from a log. With it, a limit becomes a decision point — the agent surfaces "I need $4.00 to finish this and my cap is $1.00," and a human answers.

This is the human-in-the-loop pattern applied to money, and it inverts the usual tradeoff. Normally, tighter limits mean more broken tasks, so operators loosen them over time until the limits stop protecting anything. An override path means you can set limits aggressively tight and let the exceptions escalate. Tight defaults plus a good escalation path beats loose defaults every time.

Threat model

Operational practice

Treat wallet spend the way you treat production egress or cloud cost — because operationally that is what it is.

• Per-agent telemetry. Spend by Virtual Wallet, by counterparty, by endpoint. If you cannot attribute a dollar to an agent, you cannot debug it.
• Anomaly alerting on rate, not just total. By the time a total looks wrong, it is spent. Alert on spend velocity and on first-payment-to-a-new-counterparty.
• A kill switch you have actually tested. Revoking a Virtual Wallet key should be a one-command operation someone can perform at 2am, and it should be in a runbook.
• Allow lists as reviewed config. Adding a counterparty is a code review, in the same repo as your Terraform. Not a dashboard click.
• Reconcile. On-chain settlement receipts against your own request logs. Discrepancies are your only detection mechanism for a seller behaving badly.

The governance question you will actually be asked

The whole course exists for this module. Coursera is a two-sided business sitting on a two-sided protocol, and it is dramatically more interesting as a seller than as a buyer. Here is the case, the wedge, the pilot, and the objections you should raise before someone else does.

7.1 — Frame it correctly: you are the supply side

The instinctive reading of an agent-payments announcement is "how do our agents spend money?" That is the less valuable question. Coursera's asset is not its consumption — it is that it holds data an outside agent would pay for, and that the sell side is the half that is buildable today (Module 5).

Reframed: an entire population of agents is about to start asking questions about skills, credentials, and learning — and there is currently no machine-priced way to answer them. Recruiting agents, enterprise L&D agents, career-coaching agents, workforce-planning agents. Every one of them will eventually need to know something Coursera knows.

7.2 — What Coursera has that an agent would pay for

Sort that table by "buildable this quarter with no rights questions" and one row wins by a distance.

7.3 — The wedge: paid credential verification

Take the concrete case. "Does this candidate hold this certification? Five cents to verify."

How it works today

An employer gets a link. A human clicks it and reads a page. Or, if they want it programmatically, they open a business development conversation, sign a contract, pass a security review, and get a key — six weeks and a real dollar floor, which means the only partners worth onboarding are large ones. The long tail simply doesn't get verified.

How it works with x402

The volume math — and why it's the wrong metric

Ten million verifications a year at five cents is $500,000. That is not a business line at Coursera's scale, and you should say so out loud before someone else does, because leading with the revenue number is how this proposal gets killed.

And there is a second-order effect that matters more than either: every verification is a Coursera credential proving its worth inside a hiring loop. The reason learners pay for certificates is the belief that employers check them. Making that check frictionless and machine-native strengthens the core business far more than the fee does.

7.4 — Skills Wallet vs Cloudflare Wallet

Both are called wallets. They operate at completely different layers, and conflating them will produce a bad strategy. The comparison is worth having crisp, because someone will ask.

Read the last two rows together, because that is where the strategy is.

7.5 — The buy side, briefly

Less urgent, since it needs a product that ships in "coming months," but worth naming so the strategy is complete:

• Labor-market data feeds. Job postings and skill-demand signals are currently expensive annual contracts. Spiky, exploratory usage is exactly the shape that per-query pricing serves better than an annual license.
• Licensed corpora for content generation and translation — paid per asset rather than negotiated per corpus.
• Metered inference and specialty models for translation, transcription, and accessibility checks, priced per asset processed.

The general pattern: replace annual data contracts with per-query wherever demand is spiky and exploratory. You stop paying for the ninety percent of a license you never use, and you find out what you actually need before you commit.

7.6 — A 90-day pilot

7.7 — The objections you should raise first

Raise these yourself in the first meeting. Every one is a real risk, and a proposal that names its own failure modes survives review far better than one that gets them found for it.

7.8 — Who builds it

This is a platform capability, not a product feature, and getting that wrong is how it becomes an orphan.

Platform Engineering owns the Gateway configuration, the wallet governance, and the reconciliation tooling — one team, one set of patterns. Product teams declare prices for their own resources within that framework, the same way they declare cache rules or rate limits today. The failure mode to avoid is every team building its own metering; you get six incompatible implementations and no consolidated view of what the company is selling or spending.

The most common analytical error here is treating every agentic-commerce protocol as a competitor to every other. Most of them occupy different layers. Getting the layering right is what lets you tell a real competitive threat from a complementary standard.

The layer cake

A2A, AP2, and x402 are largely complementary: communication, authorization, settlement. You could run all three. The genuine tension is narrower and more interesting.

Stripe: the incumbent that is doing both

Do not read this as Stripe-versus-x402. Stripe supports x402. The distinction that matters is the shape of each offering:

These are not really the same market. An agent buying you a $40 pair of shoes wants card rails, a dispute process, and a merchant relationship. An agent making four thousand two-cent API calls wants none of that and cannot afford any of it. Expect both to persist.

Versus the actual incumbent: API keys plus metered billing

The competitor almost nobody names is the status quo — Stripe metered billing behind an API key, which is how essentially every paid API works today.

The honest summary: metered billing is better for every customer you would have signed anyway. x402 is better for every customer you would never have talked to. That is why the 401→402 pattern in Module 5 is the right architecture — it is not a migration, it is a second door.

Versus crypto payment rails generally

x402 is built on stablecoins, but calling it "a crypto payment rail" misses what is different: it hides the chain.

• The seller sets a price in a config rule. No node, no gas, no key on a web server.
• The buyer's SDK signs. No wallet UX, no seed phrase, no bridge.
• The facilitator handles settlement. Chain selection is negotiated inside an HTTP header via the accepts array.

Previous attempts at web micropayments failed on user experience — they asked humans to manage wallets. x402 sidesteps that by not having a human in the loop. Agents are, it turns out, excellent at key management. That is the actual unlock, and it is why this attempt is structurally different from a decade of failed predecessors.

Cloudflare's real moat

What would make this fail