Cloudflare's Monetization Gateway and Pay Per Use Split Agent Payments in Two

A 402 toll you can enforce, a royalty you have to trust, and how to price your API or MCP server before the agents show up

HTTP has had a status code for "pay me" since the 1990s, and for almost thirty years nobody had a good reason to send it. On September 30, Cloudflare gave sites two reasons on the same afternoon, and the two work in opposite directions.

The first is the Monetization Gateway beta, which answers an agent's request with 402 Payment Required, takes payment inline, and then serves the resource. The second is Pay Per Use, which pays publishers when an AI product does something with their content after the fact. Read them back to back and a split appears that will shape how anyone with an API, a dataset or an MCP server gets paid by software.

One model hands the seller the meter. The other hands it to the buyer.

Why the split matters more than the launch

Cloudflare framed the week with a number that should make any site owner sit up. In its agentic web post the company says more than half of Internet traffic is no longer human, and that daily agent requests grew more than 1,700% year over year. Its summary of the economics is blunt: "revenue per request is falling while costs are rising."

Agents read your pages, call your endpoints, and never see an ad. Something has to replace the old bargain, and Cloudflare is betting on two replacements at once.

My position is simple. The toll is the one to build a business on today. The royalty is a promise, and it should go in your forecast as upside you cannot verify, because that is what Cloudflare's own description makes it.

How the toll works

The Monetization Gateway was first announced on July 1 with a waitlist. September 30 opened the beta. The mechanism is the x402 flow: a client asks for a payment-gated resource, and instead of serving it, the server "responds with 402 Payment Required and a small payload that states the price, the accepted asset, and where to pay." The buyer signs an authorization, the payment settles, and the resource comes back. In Cloudflare's words, "there is no redirect to a checkout page and no separate payment API to call."

Under the hood, verification and settlement run through Coinbase's x402 Facilitator, and payments settle in USDC on the Base blockchain. Cloudflare says it plans more rails, so stablecoins are the only option for now.

Sellers get three pricing schemes:

Fixed pricing. One price per request. Cloudflare's example is Ceramic.ai charging for web search calls.
Variable pricing. The agent is told the maximum a request could cost and pays for actual consumption. API2PDF is the example.
Origin-controlled pricing. The gateway asks the seller for a price per request, which lets AI Gateway reuse its existing pricing module instead of keeping a separate rules catalog.

The July announcement adds the part that makes this feel native to Cloudflare: rules get written the way you write other Cloudflare rules, in the dashboard or as code through the API and Terraform, with planned options to charge per route and to charge only unauthenticated callers.

That last option is the sleeper. Your logged-in human customers keep their current plans, and anonymous automated traffic meets a price. You do not have to choose between blocking agents and serving them for free.

The important property is enforcement. The seller holds the resource. If the payment does not settle, the bytes do not move. Nobody downstream has to be honest for the seller to get paid.

How the royalty works

Pay Per Use exists because a toll undercharges for some content. A research agent might fetch an article once, then quote it in a thousand reports. A per-request price captures the one fetch and misses the thousand uses.

So Pay Per Use flips the model. "Each AI company defines the use it will pay for and sets a price." Cloudflare's examples: a search service that pays "when it returns an excerpt from an enrolled page to a customer," or a shopping agent that pays "when an enrolled review shapes a recommendation." Publishers review those offers in the dashboard under Monetize, then Pay Per Use, and decide whether to accept.

Then the buyer reports each use through a JSON API with three fields: when it happened, the URL the content came from, and an event ID.

{"used_at":"2026-09-15T13:42:04Z","url":"https://example.com/article/1","id":"request-001"}

Cloudflare aggregates the reports, charges the buyer, and pays publishers monthly. It positions the product as the sequel to Pay Per Crawl: "Pay Per Crawl, which we launched in 2025, charges for access. Pay Per Use pays for what happens next."

And here is the sentence that decides how much you should trust it: "Usage is self-reported: the program terms require complete reporting, and Cloudflare checks that each reported use maps to an enrolled publisher."

Read that slowly. Cloudflare confirms that a reported use points at a real, enrolled publisher. It does not say it confirms that every use got reported. The check catches invented publishers. It cannot see uses that never got logged, and the post names no audit, no sampling, and no penalty beyond the program terms.

The pattern this repeats

Self-reported usage is an old arrangement with a long paper trail. Streaming royalties, ad network impressions and software license true-ups all ran on counts that the paying side produced, and all of them grew audit clauses, third-party measurement, and disputes over what counted. None of that makes Pay Per Use a bad idea. It makes it an early one. The buyer writes the definition of a use, sets the price, and produces the count, so the publisher's only lever on day one is the accept button.

The toll has no such gap, because counting and collecting happen in the same place.

Put this into practice

You do not need to be in either beta to start acting on this. These steps cost an afternoon.

Find your per-request cost. Before you can price a 402, you need to know what one call to your API, MCP tool or dataset costs you in compute, bandwidth and upstream fees. Pull a week of logs and divide. That number is your floor.

Split your endpoints by how they get used. Mark each one as "every request is the use" (search, conversion, lookups, tool calls) or "one fetch, many uses" (articles, reviews, reference content). The first group belongs behind a toll. The second is where a royalty might eventually pay more.

Price unauthenticated traffic first. If you sell to people today, the cleanest first move is the one Cloudflare already plans: leave signed-in customers alone and put a per-request price on anonymous automated callers. You learn what agents will pay without touching existing revenue.

Apply for the gateway if you qualify. The beta is closed and limited to eligible U.S.-based sellers and buyers, with an onboarding application in the Cloudflare dashboard.

If you accept a Pay Per Use offer, keep your own count. Your access logs already record which agents fetched which URLs. Reconcile those fetches against the monthly payout. A buyer that fetched a page 400 times and reported two uses is worth a conversation, and you can only have it if you kept the data.

Honest limitations

The toll has real gaps of its own. It settles only in USDC on Base for now, which rules out sellers and buyers who cannot hold stablecoins. The beta post does not cover refunds, failed deliveries, or Cloudflare's fees, so the unit economics of a small per-call price are unknown. And the gateway fits only resources "where every request is the use," which Cloudflare says itself.

The royalty's gap is the one covered above, and it is structural: Pay Per Use names no participating AI companies, publishes no prices, and verifies publisher identity rather than completeness. Until one of those changes, any number you put next to it is a guess.

There is also a concentration question worth naming. Both products run through one company's network. If Cloudflare becomes the default meter for agent traffic, it also becomes the default place where pricing disputes get settled, and nothing in these launches says how that would work.

Where this leaves you

The useful takeaway is not "charge agents" or "don't." It is that agent payments now come in two shapes, and they carry different kinds of risk. A toll asks the agent to trust your price. A royalty asks you to trust the agent's count.

Pick the one where you hold the meter. Then keep a copy of the other side's numbers anyway.

Sources: Cloudflare, Monetization Gateway beta · Cloudflare, Monetization Gateway announcement · Cloudflare, Pay Per Use · Cloudflare, The Internet has a second audience

Medium metadata

Title: Cloudflare's Monetization Gateway and Pay Per Use Split Agent Payments in Two
Subtitle: A 402 toll you can enforce, a royalty you have to trust, and how to price your API or MCP server before the agents show up
Tags: AI Agents, Cloudflare, APIs, Monetization, MCP
Canonical: import from the fervorai.dev URL