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.
Editorial note: Prepared October 1 as a September 30, 2026 dispatch, 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.
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 — Practical implicationsRead 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 — Practical implicationsTest 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 — Practical implicationsMake 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.
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.