Cloudflare’s new payment tools address two different events: an AI company using content after fetching it, and an agent requesting a paid resource now. A publisher should decide which event it wants to charge for before selecting a product. Neither beta guarantees that AI traffic will become meaningful revenue.
Written October 1, 2026 and dated September 30, 2026, using the dated announcements cited below. Later product developments are outside this article’s scope.
- 01Pay Per Use depends on reported useThe buyer defines an offer and reports qualifying downstream uses.
- 02Gateway payments happen at the requestHTTP 402 and x402 support access to a priced resource.
- 03Run a bounded revenue testMeasure accepted offers, paid activity and actual settlement rather than traffic alone.
- 04Name the billable event firstA pilot that cannot say whether it charges for a reported use or a paid request cannot reconcile its receipts.
01 — The evidenceTwo payment models, two evidence trails
Cloudflare’s Pay Per Use beta lets verified AI buyers propose a use definition and price. Publishers choose offers, buyers self-report qualifying uses, and Cloudflare handles billing and monthly publisher payments. This is different from charging for each crawl. Report validation does not independently reveal every unreported downstream use.
The Monetization Gateway closed beta instead returns HTTP 402 payment instructions for matched requests, using x402. Its launch is for eligible US customers. The request can itself be the billable use, such as an API lookup. Cloudflare describes settlement through a facilitator using USDC on Base; those payment arrangements should be reviewed as part of eligibility and operations.
| Product | Billable event | Evidence to inspect |
|---|---|---|
| Pay Per Use | The buyer’s defined downstream content use. | Accepted offer, reported event and settlement. |
| Monetization Gateway | A request for a priced resource. | Matched rule, payment and delivered response. |
Our earlier crawl-economics analysis covers the access-cost problem. The new decision is whether the commercial value occurs when content is fetched, when it is used in an answer or when a paid service returns a result.
02 — Practical implicationsWhy the traffic figures need their scope
In its same-day network analysis, Cloudflare reports daily AI-agent requests growing more than 1,700% over a year. It reports human traffic declines of up to 40% in heavily crawled categories, and the stated training-purpose share of crawler requests rising from 22% in spring 2025 to 52% by June 2026. These are Cloudflare’s network observations, not measurements of every site or a forecast of your revenue.
A request count is not a count of paying customers. A large increase can include repeated fetches, low-value pages or activity from buyers that never accept a commercial offer. Before setting a revenue target, identify which of your resources solves a problem for a buyer and whether that buyer can participate in the relevant payment mechanism.
Keep your existing human audience in the analysis. A pricing rule that accidentally affects ordinary visitors or search discovery could impose a cost larger than its receipts. Test the intended audience and exclusions on a small route before applying a broader rule.
03 — DefinitionRead the definition of a paid use
For Pay Per Use, compare the offer’s use definition with the value you believe you are supplying. A citation, a quoted passage and a recommendation influenced by a review are different events. The amount earned depends on which one the buyer reports and pays for, not merely on whether a crawler visited the page.
What may the buyer do?
Check permitted use, training restrictions and the effect of leaving the programme.
What can you reconcile?
Match reported URLs, dates and event identities to the accepted offer.
What was actually paid?
Distinguish estimated earnings from settled payments and investigate differences.
Choose material whose ownership and permitted licensing are clear. A page can contain third-party photographs, contributed text or other licensed material with separate conditions. An easy enrollment interface does not resolve those rights. Keep the commercial review attached to the content collection you intend to offer.
04 — GatewayTest the paid-request boundary
For a request-priced resource, define a small endpoint with a clear result and predictable cost. Check the unpaid response, payment authorization, successful delivery and retry behavior. A failed response after payment needs a deliberate recovery path; a repeated request should not create an unexplained duplicate charge.
The x402 explainer covers the protocol context. On the buyer side, the agent still needs a spending limit and a rule for when a purchase is worth making. On the seller side, payment does not remove the need for access controls, rate limits or validation of the requested operation.
Measure paid requests, completed responses, refunds or failures and operating cost over a defined pilot period. The useful margin is settled revenue minus the cost of serving and supporting the resource, with any effect on other traffic considered separately.
05 — The decisionMake the first commercial test small enough to explain
Start with one collection or endpoint, one pricing rule and an owner who can reconcile the records. Preserve a way to stop participation or reverse a rule if the result is poor. Our AI transformation work connects agent access and payment behavior to those acceptance checks.
06 — The failuresFour pilots that charged for the wrong event
The two betas bill for different events, and the guide’s sections exist because a pilot can be configured for one event while the business expects revenue from the other. The illustrative pilots below each confuse one thing. They are design examples drawn from the launch posts’ own distinctions, not publishers we have worked with.
The traffic figure as the forecast
A publisher reads the more-than-1,700% growth in daily AI-agent requests that Cloudflare’s network analysis reports over a year as its own revenue opportunity and sets a target from it. The figure is a network observation about requests, and a request is not an accepted offer, a reported use or a settlement.
The offer accepted unread
A team accepts a Pay Per Use offer because the price looks reasonable, without matching the buyer’s use definition to the value it believes it supplies. A citation, a quoted passage and a recommendation are different events, and the amount earned depends on which one the buyer reports.
The rule that caught the readers
A pricing rule on the Monetization Gateway is applied to a whole section rather than one route, and ordinary visitors and search discovery meet a 402 response. The receipts are smaller than the audience the rule cost.
The retry that charged twice
A request-priced endpoint fails after payment and the agent retries. Nobody defined the recovery path, so the pilot cannot tell whether the second request created a duplicate charge, and the reconciliation owner finds out from the buyer.
Each pilot would have produced a number and failed to explain it. The record in the next section writes the billable event down first and reconciles everything else against it.
07 — The recordA pilot record for a paid-content test
The guide asks a publisher to choose the billable event, read the definition, test the boundary and judge from settlement, and a record per pilot holds all four. The event: content use reported by a buyer, or a request for a priced resource, written as one sentence. The scope: the collection or endpoint enrolled, with the rights review attached, since a page can carry third-party photographs or contributed text under separate conditions. The rule: the offer accepted or the price set, and the exclusions that keep ordinary visitors and search discovery outside it. The evidence: for Pay Per Use, each reported URL, date and event identity matched to the accepted offer; for the gateway, paid requests, completed responses, refunds and failures over the pilot period. The costs: serving, support and reconciliation time, with any change in other traffic recorded separately. And the decision, made from settled revenue rather than estimated earnings.
An illustrative record for a reference-data endpoint reads: event, a request for one priced lookup; scope, a single API route with a predictable cost per call and no third-party material; rule, one price, with the human-facing pages excluded and tested on a small route first; evidence, paid requests, completed responses and one failed response after payment, which the recovery path refunded without a duplicate charge; costs, serving and the reconciliation owner’s time; decision, continue for a second month with the same route before adding another.
The record is also what separates the two betas when both are running. A reported content use and a paid request can concern the same page, and the record is where the two settlements are kept apart so that neither is counted twice and neither is read as the other’s result.
A difference between estimated earnings and the settled payment is the record’s most useful line, because it is the point where the two evidence trails meet. For Pay Per Use, the difference can come from a reported event that did not match the accepted offer, from a use the buyer never reported, or from a timing gap between the report and the monthly payment. For the gateway, it can come from a refund, a failed response after payment, or a request the exclusions should have kept out. The record names which, and a difference that cannot be named is the signal to pause the rule rather than extend it.
The exit is part of the record from the start. The guide asks for a way to stop participation or reverse a rule, and the record states what that looks like for the pilot: the offer that would be withdrawn, the route that would stop returning 402 responses, and what the publisher’s terms say about content already reported or already paid for. Writing the exit down before enrollment is what makes a poor result a cheap one.
Pay Per Use pays for a defined downstream use that a buyer reports; the gateway charges for a priced request, with the resource served after payment settles. A pilot that cannot name which of the two it is billing for cannot reconcile its receipts, and the record’s first line is that name.
Charge for a defined event and verify the settlement
The opportunity is clearer when the billable unit is clear. Choose content-use reporting or request-time payment according to the resource, then judge the pilot from actual paid outcomes rather than the volume of AI traffic.
Related reading: Web Search APIs for AI Agents Compared: Price and Limits.