Cloudflare Pay-Per-Use Separates Access Fees From Content Use

Cloudflare now has three publisher monetization layers for automated access: Pay Per Crawl, Monetization Gateway, and a Pay Per Use beta. They charge for different events. Pay Per Crawl prices a crawler request. Monetization Gateway can put an HTTP 402 payment challenge in front of a site, API, MCP tool, or dataset. Pay Use is designed to compensate a publisher when content is used downstream.

The distinction matters because an evergreen article can be fetched once and used many times. A working payment at the access boundary does not define what the buyer may do with the response or how to report repeated use.

One page can cross three commercial boundaries

These layers can complement one another. A publisher might allow free discovery, charge for a live data request, and separately license an answer-engine use. It should not bill the same event twice without explaining the contract.

Pay Use moves the meter downstream.

Cloudflare’s September 30 beta describes a buyer-led flow. A buyer defines a paid use, a price, and the crawler associated with collection. The publisher chooses whether to participate. The buyer reports each eligible use, and Cloudflare handles billing, publisher payment, and reporting.

1. Define Use. Name the output or workflow that creates the payment obligation.
2. Identify acquisition. Associate the crawler or collection route with that program.
3. Offer terms. State the price and the publisher content covered.
4. Publisher opts in. Participation is explicit rather than inferred from public access.
5. Buyer reports usage. Each payable event enters the settlement record.
6. Cloudflare settles. Billing, payment, and reporting move through the platform.

Cloudflare says future context could include keywords, topics, products, and other attributes. That could help publishers understand the uses that create value. The launch post does not establish a universal schema or an independent measurement system for those fields.

The audit gap is self-reporting

A downstream-use model solves one problem and creates another. The commercial unit is closer to the value event, but the publisher may not observe that event directly. In the initial model, the buyer repoUse use. A publisher therefore needs enough reconciliation data to compare acquisition, reporUse use, bilUse use, and payment.

Don’t log wallet secrets, authentication tokens, user prompts, or unnecessary personal data to make the ledger richer. The goal is commercial reconciliation, not a second surveillance system.

Use a reconciliation rate, not a revenue total.

A revenue total can look correct while hiding missing records. Track the share of buyer-reported uses that map to a valid program, price, billing line, and publisher payment. Investigate orphaned reports, adjustments, and late-arriving events by period. When crawler acquisition counts and downstream-use counts differ, treat the gap as a question, not proof of under-reporting: one acquired source can support several uses, while many crawls may produce none.

For a first pilot, set a review window and a materiality threshold before revenue arrives. Decide who can amend a use record, how a corrected report appears in the next statement, and how long both sides retain evidence. Those controls make the commercial model testable without requiring either party to expose unrelated user activity.

Request pricing still fits live service.s

Monetization Gateway remains the clearer fit when a new request creates new value. A stock API changes, a tool action executes, or a query selects a different slice of a dataset. The caller receives a 402 challenge, authorizes payment, retries, and receives the protected resource after settlement.

A payment receipt proves settlement. It does not prove that the application accepted a correct response. Request-level services still need an original request fingerprint, 402 terms, a non-secret payment reference, final response status, latency, response size, and application validation result.

A publisher decision tree

• If the response becomes stale quickly, test request pricing.
• If the request runs a tool or action, price the successful action and define failure handling.
• If one copy can support many answers, define the downstream use or license.
• If both access and reuse create value, write separate meters and prevent duplicate billing.
• If the buyer alone can observe use, require a reporting and dispute process before assigning a material price.
• If ordinary readers and public search should remain free, isolate the paid machine route rather than blocking the public page.

The Cloudflare Web Search API analysis shows why crawler identity and publisher rules belong in the acquisition record. The AI crawler guide provides the wider access-control map.

What the beta does not prove

Cloudflare has announced a beta and a settlement model, not a mature market price for publisher content. Public materials do not establish buyer adoption, independent verification of reported uses, durable interoperability, or a standard contract for every answer engine. Publishers should begin with a narrow program, a low-risk corpus, explicit terms, and a reconciliation review before expanding.

Primary sources: Cloudflare, “Pay Per Use” and Cloudflare, “Introducing Monetization Gateway“.