Cloudflare Virtual Wallets are the subaccount for APIs

Claim the name this week. Do not hand the Account Wallet, or a Stripe secret, to an agent while the envelope is still a slide.

The launch sold a live wallet#

The naive model is the one Cloudflare wrote down first. Agents bounce off login pages. A human has to add a card, mint an API key, then paste it into a prompt that will leak it. The announcement said that flow is why agents give up and kick registration back to people.

The fix, in that telling, is a wallet that holds stablecoins and pays for APIs, MCP tools, and content through x402. Search Engine Journal recapped it that way on August 12. HN recapped it that way two days after launch. A wallet you fund. An agent that spends. End of story.

That reading is generous, and it is also the one that gets you into trouble. If you treat the August 4 post as a shipping receipt, you will look for a balance, a chain, and a spend button. None of those are on the page that is actually live.

The interesting object in that post is not the stablecoin adjective. It is the split. One wallet for the human. A second wallet for the agent, on an API key, with a printed limit. That split is the product. The rest is a rail they have not attached yet.

The docs only ship a handle#

Here is the hinge. Cloudflare's wallets docs, last updated August 19, put a heading on it. What is available today.

• Reserve one wallet handle per Cloudflare account.
• Publish a page at HANDLE.cloudflare.pay that shows only the handle.
• Land on a notify list for when Wallets actually exist.

A reserved handle does not yet let you send, receive, or hold funds. That sentence is the whole live surface. The docs index is two pages. Overview and FAQ. Both are about the name.

csomar finished a reservation on the HN thread and asked the question the docs already answered. So there is actually no product yet. The clacking keyboard on that landing page is doing a lot of work for a notify list.

The wallets FAQ is just as blunt. Reservation is free. One handle per account. Reserving does not guarantee a wallet on release. First come, first served. No change, no release, no move, including after a rebrand.

Eric Lawrence almost reported cloudflare.pay to Cloudflare as a phish, because a .pay domain has no built-in relationship to cloudflare.com. He was wrong about the attack and right about the smell. The live object is a name on a new TLD. Treat it like a domain you cannot transfer.

Account Wallet stays with the human#

The announced model has two objects, and they are not interchangeable. The docs say Account Wallets are designed for humans who own Cloudflare accounts. They will add funds, delegate spend to virtual wallets, and remove funds. They may also carry a cloudflare.pay identifier.

That is the cash drawer. You fund it. You pull money back out. You decide who gets an envelope. If an agent needs to pay for an API, the wrong move is handing it this object. A shared Stripe secret is the same wrong move with a different logo.

The Account Wallet is also where identity hangs. A research agent can live at research.example.cloudflare.pay so a merchant can see the org behind it. The announcement says declaring is optional, and businesses get to decide whether unknown agents still get served. Web Bot Auth already has the keypair. The handle is the human-readable sticker on top.

Optional on the agent side is not optional on yours. If you are the one minting agents, you pick the name and you keep the drawer. The agent never sits in that seat.

Virtual Wallets are the API-key subaccount#

This is the object the title is about. Virtual Wallets are designed for agents and operate via API keys. Inside one, an agent spends according to its permissions. Maximum spend is capped by the Account Wallet owner. Cloudflare wrote that twice, once in the blog and once in the docs, same sentences.

Call it a subaccount because that is the permission shape, not because Cloudflare used the word. The agent gets a key that is not the human session. The key can spend. The key cannot empty the drawer. You mint one envelope per agent, per workflow, per employee, per environment. You do not mint one key and pray.

The exchange version of this already shipped. Binance's Agent OS puts a coding agent in a funded subaccount and blocks withdrawals by default. The transfer in is the cap. Cloudflare's announced version is the same envelope, pointed at APIs instead of an order book, with extra dials on the flap.

A shared key is cheaper to paste. It is also how you wake up to a month of inference on a prompt that said please. The subaccount is annoying on purpose. Annoying is the feature.

This is also not an OAuth consent screen. Agents already request every scope they might need. That catalog is about tools they might call. A Virtual Wallet is about dollars they might spend. Different grant. Do not collapse them because both say agent.

The three knobs are the cap#

Cloudflare's announcement names three guardrails. An allowance. An allow list. A maximum transaction size. Those are the knobs. They are examples rather than a published schema. They are still the only controls Cloudflare has committed to in public, so they are what you should plan against.

If an agent is responsible for $10, you worry less than if it holds $1,000. That line is the argument, not a price sheet. A few cents per API try means ten dollars buys a lot of sampling. Keep the envelope small so the agent can wander.

Give every employee a $100 per week inference budget and you get the org version of the same trick. Provision the Account Wallet. Mint a Virtual Wallet per employee with that rule. Anyone who blows past it asks a human who can actually move the Account Wallet. Unexpectedly fast spend is supposed to page a person, not auto-top-up.

• Allowance is the period cap you should plan, weekly inference or a one-shot eval envelope. Size it like a prepaid card. Cloudflare has not published the reset clock or the API.
• Allow list is who you will let the envelope pay. Fill a merchant set. Cloudflare has not said what an empty list does, so treat an empty one as unknown, not as deny-by-default.
• Max transaction is the single-purchase ceiling you should print. Sampling a $0.02 API is the point. An accidental $80 fine-tune is what this knob is for, once it exists.

None of those knobs are live. Plan them anyway. When funding lands, the people who already know the three numbers will mint the envelope. The people who wait for a dashboard tour will paste the Account Wallet into .env and call it a prototype.

Do not confuse the envelope with the rail. x402 is how a request pays. Agentic Payments on the Agents SDK already speak x402 and MPP without a Cloudflare Wallet. Monetization Gateway is the seller side, waitlisted since July, charging for pages, datasets, APIs, and MCP tools. Kitesurf is browse. A Virtual Wallet is none of those. It is the cap you put on the buyer.

If you only remember one knob, remember max transaction. Allowance leaks slowly. An allow list only helps if you fill it. A missing per-call ceiling is how a loop becomes a bill.

Claim the handle then wait#

The action this week is boring, and it is the right one. Reserve the handle. Write down that it is a name, not a balance. Decide the three numbers you will stamp on the first Virtual Wallet. Do not hand an agent the Account Wallet, a Stripe secret, or the Binance main account while you wait for Cloudflare to attach funds.

merek already watched a unique company name and its variants get reserved on HN. The FAQ will not help. There is no move, no release, no rebrand path. If the name matters, grab it. If someone else grabbed it, file abuse and pick a worse one. Squatting is the tax on a first-come TLD with no domain check.

When spend does land, mint the envelope. One Virtual Wallet per agent, with an allowance you can afford to lose, an allow list of vendors you actually want, and a max transaction small enough that a runaway loop is an annoyance. The human keeps the drawer. The agent keeps the key to the envelope. That is the whole control plane.