Two Cloudflare Agent Billing Betas Turn Web Monetization Into a Question of Who Holds the Meter

Cloudflare put two agent-billing products into beta on September 30, as part of its Birthday Week launches. The Monetization Gateway lets a seller answer an unpaid request with HTTP 402 and collect a stablecoin payment before the resource is delivered. Pay Per Use lets an AI company offer a price for a specific use of a publisher’s content, then report each use so Cloudflare can bill the company and pay the publisher.

Cloudflare presents them as halves of one idea. The more useful way to read them is as two answers to a question the payment rail hides: who holds the meter? A request can be measured at the edge, because the edge sees it. A use of content happens later, inside someone else’s product, where no proxy can watch. So one model leans on signatures and ceilings, and the other leans on a buyer’s honesty. Below is what each model verifies, what it only asserts, and the numbers that decide whether the economics work.

I also sent the launch post’s own unauthenticated example request to a live Gateway customer and decoded the reply, which is shown in full. One caveat first: Cloudflare describes its role as building “the rails for visibility, identity, controls, and settlement,” so its market statistics are its own data and are labelled that way here.

What Cloudflare shipped

Monetization Gateway: a paywall for agents

Cloudflare’s own shorthand is a “paywall for agents.” A seller writes a rule that matches a URL, headers, query parameters or caller attributes, chooses an audience, picks a pricing scheme and sets a price. The Get started docs offer two audiences, Everyone or Verified Bots (bots identified by BotBase), and two schemes. Fixed charges the same amount per request. Variable authorizes a maximum and requires the seller to report the actual amount. The minimum price is $0.001. “Payments settle on the Base blockchain using USDC, a stablecoin pegged to the U.S. dollar,” through Coinbase’s x402 facilitator, and Cloudflare says it handles verification, retries and keeping up with protocol changes.

It is a closed beta with hard edges. “Buyers and sellers must be based in the United States,” and the eligibility page adds that a seller needs a credit card on file, an account older than 60 days and a proxied zone older than 30 days. The Get started page also assumes a receiving wallet. Four customers are shown live. Cloudflare’s own AI Gateway lets U.S.-based customers pay for inference on a select set of models by adding a PAYMENT-METHOD: x402 header. Ceramic.ai sells agent search with fixed pricing and no API key. Stocktwits built a separate agent-facing path and left its existing API and enterprise data products unchanged. API2PDF, a PDF-generation API, returns a 402 when a request arrives without an API key. A companion post adds that “thousands of sellers joined the waitlist” and that Cloudflare is “our own first customer.”

Pay Per Use: pay for the use, not the crawl

Pay Per Use reverses the order of events. A buyer defines the use it will pay for and sets a price. A publisher reviews offers in the Cloudflare dashboard and accepts or declines each one, with no change to its origin. The buyer then reports each use as one line of JSON (a timestamp, the URL the content came from and an event ID), and Cloudflare will “aggregate reported uses, charge the buyer, and pay publishers monthly through their connected payment account.”

The reasoning is about what crawlers do versus what they use. “AI products fetch far more than they use,” the post says, and “Charging for every crawl makes the buyer pay before it knows what it needs, and many buyers won’t.” Pay Per Crawl, launched in 2025, “charges for access”; Pay Per Use “pays for what happens next.” The post names no participating buyer or publisher, and its two example offers (a search service paying when it returns an excerpt, a shopping agent paying when a review shapes a recommendation) are hypothetical. Our July 1 coverage of Cloudflare’s agentic-web report noted that Cloudflare was moving from Pay Per Crawl toward Pay Per Use; this is that plan entering beta.

The 402 handshake, decoded

The Monetization Gateway post ends its API2PDF example with a curl command that makes a request without an API key. I ran a version of it at about 19:26 UTC on September 30, piped through a decoder. It costs nothing, because nothing is signed or paid; the server just states its terms.

curl -si -X POST https://v2.api2pdf.com/chrome/pdf/html \
  -H "Content-Type: application/json" \
  --data '{"html":"<p>Hello from an AI agent</p>"}' \
  | grep -i '^payment-required:' | cut -d' ' -f2 | tr -d '\r' | base64 -d

The server answers HTTP/1.1 402 Payment Required with an empty JSON object as the body. The terms travel in a PAYMENT-REQUIRED header as base64-encoded JSON, which decodes to the object below (pretty-printed here, with two wallet addresses shortened).

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "resource": { "url": "https://v2.api2pdf.com/chrome/pdf/html" },
  "accepts": [
    {
      "scheme": "upto",
      "network": "eip155:8453",
      "amount": "50000",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "payTo": "0x4F69…7599",
      "maxTimeoutSeconds": 3600,
      "extra": {
        "name": "USD Coin",
        "version": "2",
        "facilitatorAddress": "0x2A89…EB5A"
      }
    }
  ]
}

What each field says

• x402Version and error: protocol version 2, and a statement that the retry has to carry a PAYMENT-SIGNATURE header, meaning the buyer’s signed authorization.
• scheme: upto is the variable-pricing scheme. In the x402 v2 spec, the amount “represents the maximum authorized amount at verification time, but the actual amount to settle at settlement time.”
• network: eip155:8453 is a chain ID in the CAIP-2 format the v2 spec uses. A read-only eth_chainId call to Base’s public RPC endpoint returns 0x2105, which is 8453, so the payment settles on Base as Cloudflare says.
• amount and asset: the spec defines the amount as a “Required payment amount in atomic token units.” Asking the token contract directly through eth_call (name(), symbol() and decimals()) returns USD Coin, USDC and 6 decimals. So 50000 units is 0.05 USDC, a ceiling of about five cents per request. Cloudflare’s rules docs agree: “One atomic unit equals $0.000001.”
• maxTimeoutSeconds: the maximum time allowed for payment completion, here an hour, the same value as in Cloudflare’s own docs example (the spec’s example uses 60 seconds).
• payTo and extra: the seller’s receiving wallet, plus scheme-specific extras, here the token’s name and version and a facilitator address.

You can check the chain and the token yourself with read-only calls that spend nothing:

# chain ID: prints 0x2105, which is 8453
curl -s https://mainnet.base.org -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

# decimals() on the asset contract (selector 0x313ce567): the result ends in 06
curl -s https://mainnet.base.org -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_call","params":[{"to":"0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913","data":"0x313ce567"},"latest"],"id":1}'

What the reply does not say

Two things stand out. First, the launch post says API2PDF “settles only the actual consumption” and suggests an agent could pay it “a fraction of a cent” for a PDF. Both can be true, because 50000 units is a ceiling and not a price. But an agent that caps every authorization below five cents would refuse this request even if the settled amount were the gateway’s $0.001 minimum, a tenth of a cent. Second, nothing in the response shows what the real price will be. Under variable pricing that number is reported later by the seller’s own origin, which is the point the next section turns on. This is one request at one moment, and API2PDF can change its terms at any time.

A status code the HTTP spec left unused

HTTP reserved the code for exactly this and never defined it. RFC 9110, section 15.5.3, says in full: “The 402 (Payment Required) status code is reserved for future use.” The meaning here comes from the x402 spec, which Cloudflare’s July announcement describes as an open protocol it is building with “a coalition of more than 25 industry leaders via the x402 Foundation,” not from HTTP itself.

Who holds the meter

Put the three billing modes side by side and the difference is the meter, not the money.

Fixed pricing: the signature is the price

With fixed pricing there is nothing to measure. The origin receives a PAYMENT-CONTEXT header holding a JSON Web Token. The payment-validation docs tell sellers to check it against a pinned key set, require Ed25519 signatures and, if the header is absent, “treat the request as unpaid and unverified.” Cloudflare “strongly recommends” verifying payment at the origin.

One sequencing detail deserves a seller’s attention. In the documented flow the gateway verifies the authorization, the origin produces its response, and only then does the gateway settle through the facilitator. For the exact scheme, the x402 spec has the facilitator check the signature, the payer’s balance and the time window, and simulate the transfer before settlement, which narrows the gap between verification and settlement. The x402 page says that “If verification or settlement fails, the Gateway does not serve the protected resource,” so the buyer gets nothing. It does not say who absorbs the origin’s work in that case. For a cheap lookup that hardly matters. For an expensive origin call it is worth asking.

Variable pricing: the seller’s origin holds the meter

Under variable pricing the buyer signs a ceiling and the seller reports the real amount. The same docs tell the origin to set PAYMENT-SETTLEMENT only on a successful response, never on a status of 400 or greater, with a JSON value holding the amount in atomic units. “If the actual amount exceeds the authorized maximum, Monetization Gateway settles the authorized maximum instead,” and “Nothing will be settled if the specified amount is zero.” The gateway creates the receipt after settlement and removes the header from the response the buyer sees. The docs label this origin-side handshake “Cloudflare-specific” and say the headers “are not x402 client headers,” so the meter interface is Cloudflare’s own design rather than part of x402.

So the buyer’s protection is the ceiling and nothing else that the docs describe. Cloudflare says every paid request leaves “a receipt showing what was bought and that it was paid for,” which proves payment but does not obviously let a buyer audit the seller’s meter. That is an ordinary trade in metered services, and a signed cap is the same instinct as the scoped tokens in our confused-deputy tutorial: bound the authority before the agent acts.

Pay Per Use: the buyer holds the meter

Pay Per Use has no ceiling because nothing is signed per use. “Usage is self-reported: the program terms require complete reporting, and Cloudflare checks that each reported use maps to an enrolled publisher.” That check confirms the URL belongs to a participating publisher; the post does not describe a check that every use was reported. Cloudflare can see crawls at its edge (its Business Insights dashboard shows which crawlers visit and what they take), but a use happens later inside the buyer’s product, and the post describes no way to observe it. The companion post says only that “Cloudflare checks those reports.”

Two more details shape the trust. Each buyer defines its own use, and “There won’t be one definition of use,” so the same article can be paid for one kind of use and not another. And Cloudflare says it is working with AI companies to report more context per use, such as keywords, topic or product, “with no personal data being exchanged.” That would help publishers, but it is also more self-reported data. Publishers do get a dashboard of reported uses and estimated earnings by buyer and domain, which Cloudflare pairs with its answer-engine tool. We covered that tool in our AEO dashboard piece.

Why Cloudflare needs both models

The split follows where value becomes visible. For APIs, tools and data, Cloudflare says, “every request is the use,” so the request can carry the payment. For content the picture is different: “a page might be crawled once and used a thousand times.” Charging at the crawl prices the wrong event. Cloudflare’s July plan post made a related point, that AI crawlers “already request content anywhere from a hundred to tens of thousands of times for every visitor they send back,” so crawl counts say little about the value delivered. The same argument about the unit of account is playing out in enterprise software, where Salesforce wants to charge for AI outcomes but is still working out how, as we covered.

The numbers behind the pivot

Cloudflare’s “second audience” post supplies the market case. Every figure below is Cloudflare’s own measurement of its network.

• Requests per second averaged 63 million at the end of 2024 and have “almost doubled” to 115 million, with peaks above 150 million.
• Daily requests from AI agents grew “by more than 1,700%” over the past year, and “for the first time, more than half of Internet traffic wasn’t human.”
• AI training made up 22% of the crawler requests Cloudflare saw in Spring 2025 and 52% by June 2026, judged by the crawlers’ stated purpose.
• “Fewer than 1% of sites on Cloudflare block search crawlers, while 17% block training.”
• “More than 50 publisher-AI deals have been signed since 2023,” nearly all of them “bespoke and bilateral.”

One inconsistency is worth flagging. The Monetization Gateway post describes agents as “the predominant source of traffic on the Internet.” The companion post is more careful: more than half of traffic was not human, and agents are a fast-growing slice that sits “somewhere between humans and traditional bots.” Neither post gives a number for agents’ share of total traffic, so the first claim is an assertion rather than a measurement.

The price floor and the rail

The floor price and the payment rail interact. The Gateway’s rules docs set a minimum settlement amount of $0.001 and a maximum price of $100. Coinbase’s documentation for the facilitator that Cloudflare names says “The first 1,000 onchain Facilitator transactions each month are free, then each additional onchain transaction costs $0.001,” that “Payment verification is always free,” and that “With exact and EVM upto, each accepted payment settles in one onchain transaction.” The same page describes a batch-settlement scheme in which “one onchain transaction can process thousands of payments.” Cloudflare’s docs, as I read them, describe fixed and variable pricing and do not mention batching, and none of the pages I read says who bears the facilitator’s fee when the gateway settles through it.

That leaves the floor ambiguous. As an illustration at list price, and only if the seller bore the fee and every payment settled on its own: a seller charging $0.002 a request across 100,000 requests in a month would gross $200 and owe about $99 in facilitator fees (99,000 billable transactions at $0.001), nearly half of revenue. At the $0.001 minimum, the fee would equal the price. Neither condition is confirmed by the documents, which is exactly why the fee question decides whether the floor is usable.

A scale check

The same Coinbase page says its facilitator “has processed more than 100 million transactions and $28 million in payment volume across Base and Solana alone.” That works out to under 28 cents per transaction on average, and even the stated floor of 100 million transactions is under a second of Cloudflare’s 115 million average requests per second. The units differ, since requests are not payments, but the gap shows how early this market is and why both products launch as betas. In Cloudflare’s words, “Pricing and discovery aren’t solved yet.”

Other limits are stated plainly: U.S.-based buyers and sellers only, one payment rail (USDC on Base) with Cloudflare planning to “support additional payment rails,” and sanctions screening on the Coinbase side, whose checks “identify and decline payments involving sanctioned or high-risk addresses.”

What to check before you switch either on

If you sell per request

• Validate the PAYMENT-CONTEXT token at the origin, and treat a missing header as an unpaid request.
• Decide the audience deliberately. Everyone charges all matching traffic; Verified Bots charges only the bots BotBase identifies. “Charge agents, not humans” was the most common waitlist request, so this setting is the real policy choice.
• Follow Stocktwits and keep a separate agent-facing path instead of changing the API your existing customers use.
• Prefer fixed pricing unless you can report actual amounts honestly and cheaply, and price above the floor until you know how facilitator fees are handled.

If you publish content

• Read each program’s terms. They define what counts as a use and any restrictions on training, and you can stop participating if an arrangement no longer works.
• Ask how complete reporting is verified, and compare reported uses with the crawl data in Business Insights yourself.
• Expect monthly settlement through your connected payment account, not payment per request.

If you build an agent

• Treat every signed authorization as a spending limit. The five-cent ceiling in the live response above was set by the seller, so check it against your per-call budget before signing.
• Neither launch post covers buyer-side controls such as per-task budgets or wallet custody. The ceiling in an upto authorization is the only limit visible in the documents I read.

What to watch next

• Which buyers join Pay Per Use. The post names none.
• Whether “complete reporting” gets an audit mechanism beyond contract terms.
• How facilitator fees are handled, and whether batch settlement reaches the Gateway.
• Identity on the 402 side: Cloudflare says it plans to “incorporate identity primitives.”
• Geography and rails: U.S. only and USDC on Base for now.

Cloudflare says its rails run on open standards, x402 and Web Bot Auth, and that “Cloudflare is one option, not the whole stack.” In the beta itself, sellers need a Cloudflare account and a proxied zone, settlement runs through Coinbase’s facilitator, and Cloudflare’s own AI Gateway is one of the four live customers. That is a normal shape for a first beta. The open-standard claim is easiest to check at the x402 layer, where the spec and the decoded 402 above are public. The origin handshake (PAYMENT-CONTEXT and PAYMENT-SETTLEMENT), the billing, the bot identity and the settlement path around it are Cloudflare’s.

Bottom line: the Monetization Gateway is the enforceable model, because the edge sees every request and a signature bounds every charge, though variable pricing hands the meter to the seller. Pay Per Use is the model for value that shows up later, and it rests on contract terms and a buyer’s own reports. Sellers choosing between them are choosing where to put their trust, and the betas exist to find out which side of that trade agents and AI companies will accept.

Sources and method

• Cloudflare: Monetization Gateway beta, Pay Per Use, The Internet has a second audience, the July 1 announcement, and the Monetization Gateway docs.
• Coinbase: the CDP Facilitator documentation. Protocol: the x402 v2 specification and RFC 9110.
• First-hand checks: one unauthenticated request to API2PDF at about 19:26 UTC on September 30, 2026, with the PAYMENT-REQUIRED header decoded, and read-only JSON-RPC calls to Base’s public endpoint for the chain ID and the asset’s name, symbol and decimals. No payment was signed or sent.