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

If agent traffic is adding to the load on your API, MCP tool, or dataset behind Cloudflare, charging for each request is another option alongside blocking bots or absorbing the cost. Cloudflare’s Monetization Gateway, announced in closed beta on 2026-09-30, puts that payment into the request itself.

The gateway returns an HTTP 402 payment challenge, prices per use, and settles in USDC on Base through Coinbase’s x402 Facilitator. For the agent operator, the question is just as practical: when the runtime reaches a paid endpoint, who decides whether the resource is worth buying?

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 payment happens in the HTTP exchange. 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.” Cloudflare says there is no redirect to a checkout page and no separate payment API to call.

A browser can show someone a paywall; here, an HTTP client can settle the payment programmatically. 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, Cloudflare handles “payment verification and settlement 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.

Settlement happens before delivery, so the request has to wait for payment verification. Cloudflare publishes no figures for that extra delay. Paying in USDC on Base also leaves custody, key management, and compliance questions with whoever funds the wallet, as we examined in agent wallet custody and replay risks. Before relying on this flow, you would also need answers about refunds, disputes, and chargebacks; the announcement does not address them.

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: “It’s 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.”

Start with what the buyer gets from a request. Per-request pricing fits an inference call, search query, or tool invocation when each request consumes the resource once. A page is different: a crawler can pay for it once and keep reusing the text. A 402 challenge on the next crawl cannot recover the value of that reuse. Pay Per Use instead depends on buyer reporting; Cloudflare describes the “verified buyer” protections, but they have not been independently verified.

This table reflects Cloudflare’s product framing, not an independently tested result. Check how buyers use your responses before choosing a route. If agents cache and redistribute your “API” responses, the crawled-content column may describe your problem more closely than the API label does.

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.

For inference buyers, the scope is narrower. Starting 2026-09-30, U.S.-based Cloudflare customers can pay at request time on a select set of AI Gateway models by adding PAYMENT-METHOD: x402. The post’s curl example against /accounts/$ID/ai/run renders the header as Payment-Method: x402. This remains a closed beta for U.S. customers and select models.

Paying a bill at request time does not cap that bill. The budget control still has to come from somewhere else, the problem we examined in earlier coverage of capping inference bills.

The four production use cases, and what is actually verified

Cloudflare described four production use cases in the announcement:

• 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.

Those qualifications matter before you spend time building a paid endpoint. The adoption question is whether it will have buyers. The independent volume measurements below give a more cautious picture than the launch narrative.

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

For an agent operator, each metered endpoint becomes a spending decision at HTTP speed. The protocol can execute payment without deciding whether that payment is useful. 402Pilot, an x402 decision-layer paper, describes 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 treat 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.

Before giving an agent a wallet and access to a 402-protected endpoint, I would want its runtime to handle the decisions that the protocol leaves open:

• 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. Payment verification depends on facilitators, so their security matters to the servers and clients using them. 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; some were fixed and others were still being addressed (arXiv:2607.19545). Cloudflare settles through Coinbase’s facilitator. That makes the history relevant when assessing the dependency, but these confirmed bugs do not establish a flaw in Cloudflare’s gateway.

Payment metadata can disclose intent. A middleware study describes resource_url, description, and reason strings reaching the payment server and centralized facilitator API before settlement (arXiv:2604.11430). If an agent sends “researching competitor X’s pricing” as a reason string, it discloses that intent to the recipients of that field. Check which metadata your client sends and what those recipients retain. The same paper ships an open-source middleware for filtering PII and enforcing spending policies at author-reported p99 latency of 5.73 ms inside a 50 ms overhead budget. That measures latency in the tested setup; it does not establish complete redaction or default deployment.

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.

The dashboard totals 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. Their dates and totals differ. The census also shows why a transaction count cannot answer a seller’s more useful question: how much traffic comes from someone else’s agent willing to pay for this resource? The cited measurements do not establish that demand for this gateway.

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 gateway evidence 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 there are no published measurements of latency overhead, fees, dispute handling, or behavior outside Cloudflare’s network.

The settlement census cannot yet confirm that enough independent agents will pay per request to justify the metering work. If your resource fits the per-request model, build the 402 handling with that uncertainty in mind. Keep demand as a question to measure in your own logs, rather than a result the announcement has already established.