Charging AI Agents for API Calls: How Cloudflare's HTTP 402 Gateway Works

If your API, MCP tool, or dataset sits behind Cloudflare and agent traffic keeps rising, you now have a third option besides blocking bots or absorbing their load: Cloudflare’s Monetization Gateway, announced in closed beta on 2026-09-30, returns an HTTP 402 payment challenge inline with the request, prices per use, and settles in USDC on Base through Coinbase’s x402 Facilitator. Agent operators face the mirror-image question: what happens when your runtime hits that challenge, and who decides whether to pay?

What shipped: the Monetization Gateway closed beta

The gateway lets domain owners charge agents for websites, APIs, MCP tools, or datasets behind Cloudflare’s network, priced per use and configured through the Cloudflare Dashboard. Cloudflare says the closed beta arrives with four customer use cases already in production, three months after the plan was first announced. That production claim is vendor-reported and unverified; the announcement names all four, listed below.

The defining design choice is where payment happens. Per the launch post, the gateway uses the HTTP 402 Payment Required status code “so buyers can offer payment for a resource over HTTP, inline with the request for the resource itself… there is no redirect to a checkout page and no separate payment API to call.” That is the difference between a paywall a browser can render and a paywall an HTTP client can settle programmatically within the HTTP exchange itself. We covered what per-request API billing needs when Cloudflare opened the waitlist in July; the closed beta is the first time the mechanics are documented against running customers.

How the 402 flow actually works

The wire protocol is the x402 pattern, which predates Cloudflare’s involvement. An independent implementation study of x402 composed with agent-to-agent protocols describes the core exchange: if a client omits payment credentials, the server responds with HTTP 402 and the required payment metadata in the response body, and the client retries with a signed payment authorization in a payment header. Cloudflare’s gateway automates both ends of that exchange for resources on its network:

1. Seller defines rules. Pricing rules match any part of a request: URL, headers, query parameters. The seller picks a pricing scheme and a payment destination.
2. Buyer gets challenged. An unpaid request receives a 402 response carrying payment instructions.
3. Buyer signs and retries. The buyer’s wallet signs an authorization and resubmits the request with it.
4. Settlement before delivery. Per Cloudflare’s announcement, “payment verification and settlement [run] through Coinbase’s x402 Facilitator,” and buyers “receive the resource after the payment has been settled.” Settlement lands on the Base blockchain in USDC, a stablecoin pegged to the dollar. Cloudflare handles failures, retries, analytics, and x402 protocol changes.

Two properties of that flow deserve attention. First, the resource is delivered only after settlement, so the latency of payment verification sits on the request path; Cloudflare publishes no overhead figures. Second, settlement in USDC on Base means custody, key management, and compliance questions move to whoever funds the wallet, a point we examined in our earlier look at agent wallet custody and replay risks. The announcement does not address refunds, disputes, or chargebacks at all.

Seller decision: per-request resource or crawled content?

Cloudflare’s own product framing splits the problem, and it is the most useful decision rule in the announcement. Per the launch post: the gateway “is built for resources where every request is the use, like APIs, tools, and data. High-value content is different: a page might be crawled once and used a thousand times. For that, Pay Per Use offers a trusted network of verified buyers who report each use and pay for it.”

The logic is mechanical, not ideological. Per-request pricing works when each HTTP request consumes the resource once: an inference call, a search query, a tool invocation. It fails when the value escapes the request, because a crawler that pays once for a page can reuse the text indefinitely, and no 402 challenge on the next crawl recovers that value. Pay Per Use substitutes reporting trust for per-request enforcement; the “verified buyer” protections are described only by Cloudflare and are unverified independently.

This mapping is Cloudflare’s product framing, not an independently tested result. Sellers should validate it against their own traffic: if your “API” responses get cached and redistributed by agents, you may be in the crawled-content column whether you like it or not.

Pricing rules and the PAYMENT-METHOD: x402 inference option

Sellers get two ways to set price. The default is a rules catalog inside Cloudflare: match requests by URL, headers, or query parameters and attach a scheme. The alternative is origin-controlled pricing, where the gateway asks the seller’s origin for pricing information per request instead of consulting its own rules. Cloudflare cites AI Gateway’s existing pricing module as an example of the origin-controlled pattern; that detail comes from the announcement and has not been independently exercised.

The buyer-facing half of the inference story is narrower. Starting 2026-09-30, U.S.-based Cloudflare customers can pay for inference at request time on a select set of AI Gateway models by adding the header PAYMENT-METHOD: x402 (the post’s curl example against /accounts/$ID/ai/run renders it as Payment-Method: x402). The scope limits matter: U.S. customers only, select models only, closed beta. Note the asymmetry: request-time x402 payment settles a bill; it does not cap one. Budget enforcement still has to come from somewhere else, a problem we examined in earlier coverage of capping inference bills.

The four production use cases, and what is actually verified

Cloudflare says four customer use cases are in production today, and the announcement names all four:

• Cloudflare AI Gateway: inference paid at request time via the PAYMENT-METHOD: x402 header, detailed above.
• Ceramic.ai: a web search API built for agents, selling per-query search under the gateway’s fixed pricing scheme.
• Stocktwits: market signals such as sentiment, message volume, and trending tickers, priced per request through a separate agent-facing path that leaves existing API and enterprise data products unchanged.
• API2PDF: PDF generation over REST, returning a 402 when a request arrives without an API key, quoting a variable maximum price, and settling only the actual consumption.

Treat all four as vendor-selected reference customers in a closed beta; none has independent verification, and Cloudflare’s broader framing that agents are becoming a predominant source of Internet traffic is a vendor claim, not a measured finding.

This is not pedantry. The adoption question determines whether building a paid endpoint has any buyers, and the independent measurement literature is considerably cooler than the launch narrative, as the volume numbers below show.

Buyer side: your agent hits a 402. Then what?

For agent operators, the gateway turns every metered endpoint into a spending decision executed at HTTP speed. The protocol itself answers none of the interesting questions. 402Pilot, an x402 decision-layer paper, states the gap directly: “Programmable-payment protocols such as x402 enable per-request micropayments, but they do not determine which payable service an autonomous agent should buy under a finite wallet.” The authors formalize agent payment as an online decision problem, contribute a policy (PA-DCT) and a benchmark of 823 effective tasks, and validate the interface against a real HTTP 402 flow locally.

The practical consequence: before a wallet-bearing agent touches a 402-protected endpoint, its runtime needs a layer the protocol does not provide:

• Spending policy. Per-task and per-day caps, an allowlist of payable hosts, and a maximum price per resource class. Without this, a retry loop becomes a drain loop.
• Idempotency tracking. Which challenges were already paid, so a retried request does not pay twice. The replay evidence below shows this is not hypothetical.
• Metadata hygiene. What your agent puts in the payment metadata, because it is not private (also below).
• Failure handling. The resource arrives only after settlement, so the agent must treat “paid, waiting on delivery” as a distinct state, and decide what to do when delivery never comes. The announcement is silent on refunds.

Known attack surface: replay, proxies, facilitators, PII

Independent security research on x402 predates this launch and applies to anything built on the protocol, though no source has tested Cloudflare’s gateway specifically. Four findings shape the risk picture.

Replay and idempotency. A five-attack analysis of x402 found, in author-reported live and testnet measurements, a single payment reused for 248 resource grants, a header/proxy confusion that leaked through 100% of tested nginx configurations, and server-selection attacks in which one crafted server captured 71.8% of payment opportunities and five Sybil servers captured 60.2%. The authors describe the replay case as “a classic idempotency failure,” with the mistake sitting “between a bearer payment header and an asynchronous on-chain settlement path.” Web engineers solved exactly-once payment handling years ago; x402 reopens the bug class at the protocol layer.

Facilitator centralization and confirmed bugs. Because verification runs through facilitators, their security is load-bearing for the whole ecosystem. A disclosure campaign reported findings to 14 of 15 affected parties in January 2026; as of 2026-02-06, Coinbase, PayAI, and Mogami had confirmed six distinct vulnerabilities in facilitators and SDKs used downstream by many servers and clients, with some fixed and others still being addressed (arXiv:2607.19545). Coinbase operates the facilitator Cloudflare’s gateway settles through, so this history is directly relevant, even though the confirmed bugs are not evidence of flaws in the gateway itself.

Payment metadata leaks in plaintext. Every x402 payment embeds resource_url, description, and reason strings that travel in plaintext to the payment server and the centralized facilitator API before any on-chain settlement, typically without a data processing agreement (arXiv:2604.11430). An agent that writes “researching competitor X’s pricing” into a reason string is broadcasting intent. The same paper ships an open-source middleware that redacts PII and enforces spending policies at author-reported p99 latency of 5.73 ms inside a 50 ms overhead budget, evidence that the fix is cheap, not that anyone ships it by default.

Deployed configurations exceed the safe envelope. A systematic flaw taxonomy across agentic payment protocols catalogs five flaw classes and warns that “deployed configurations frequently exceed their documented safe envelope” (arXiv:2605.30998). The same paper maps the competing protocols: x402 (Coinbase), MPP (Stripe and Tempo), AP2 (Google), and TAP (Visa). These are not interchangeable, and x402 carries by far the most deployed traffic, settled almost entirely in USDC, with three facilitators processing the bulk of volume.

Reading the volume numbers honestly

Any “agent economy has arrived” framing rests on settlement counts, and the population-scale evidence says those counts are not adoption. A 280-day census of x402 on Base found 136,708,672 settlements worth $44,121,383.81 gross, yet 84.98% of the count was operator-internal, 21.20% fictitious and 63.78% internal to a linked cluster, with payer, recipient, and value Gini coefficients all above 0.98. Genuinely independent value is bounded between $187,861.35 that demonstrably reaches a nameable service and $20,258,746.09 (45.92% of value) not provably manufactured. The authors’ summary is blunt: settlement count measures manufacturability, not adoption.

Dashboard figures circulate that sound larger: x402scan reports over 150M on-chain transactions, over $40M cumulative volume, over 400K buyers and over 80K sellers, while a Dune-based count cited by another paper puts all-time transactions near 130M as of May 2026. The dashboards disagree with each other on dates and totals, and the census explains why neither answers the question a seller actually cares about: how much of that traffic is someone else’s agent willing to pay for my resource. The honest answer, as of this launch, is that nobody has measured it.

Verdict: adopt the plumbing, wait on the proof

For per-request resources such as APIs, MCP tools, and inference, Cloudflare’s gateway removes most seller-side payment engineering: write pricing rules, let the edge return HTTP 402 challenges, and let Coinbase’s x402 Facilitator verify and settle in USDC on Base. If your resource is high-value content that gets crawled once and reused, per-request charging is the wrong instrument; Cloudflare itself routes that case to its Pay Per Use verified-buyer network, whose protections remain vendor-described. On the buy side, do not ship a wallet-bearing agent without a spending-policy and idempotency layer: the protocol executes payments, but it does not decide what is worth buying, and the replay and facilitator flaws above are documented, not theoretical.

The strongest limitation is the evidence itself. Everything about the gateway comes from a single vendor announcement in closed beta: the four use cases are vendor-reported, request-time inference payment is US-only on select models, and no published measurement covers latency overhead, fees, dispute handling, or behavior outside Cloudflare’s network. The economic bet underneath, that enough independent agents will pay per request to justify metering, is precisely what the settlement census cannot yet confirm. Build the 402 handling now if your resources fit the per-request model; treat the demand side as an open question you will have to measure on your own logs.

Frequently Asked Questions

Which four customer use cases are in production with the Monetization Gateway?

• Cloudflare AI Gateway: inference paid at request time via the PAYMENT-METHOD: x402 header, detailed above.
• Ceramic.ai: a web search API built for agents, selling per-query search under the gateway’s fixed pricing scheme.
• Stocktwits: market signals such as sentiment, message volume, and trending tickers, priced per request through a separate agent-facing path that leaves existing API and enterprise data products unchanged.
• API2PDF: PDF generation over REST, returning a 402 when a request arrives without an API key, quoting a variable maximum price, and settling only the actual consumption.

What is the difference between the Monetization Gateway and Pay Per Use?

Per the launch post: the gateway “is built for resources where every request is the use, like APIs, tools, and data. High-value content is different: a page might be crawled once and used a thousand times. For that, Pay Per Use offers a trusted network of verified buyers who report each use and pay for it.”

What security risks are documented for x402 payments?

Replay and idempotency. A five-attack analysis of x402 found, in author-reported live and testnet measurements, a single payment reused for 248 resource grants, a header/proxy confusion that leaked through 100% of tested nginx configurations, and server-selection attacks in which one crafted server captured 71.8% of payment opportunities and five Sybil servers captured 60.2%.