Cloudflare is now testing something we've been talking about in agentic payments for a while: letting an AI agent pay for an API or tool as part of the HTTP request itself.
Its new Monetization Gateway is now in closed beta. A seller can put a price on an API, MCP tool, website or dataset, return an HTTP 402 response, and let the buyer authorize payment before getting the resource.
Until now, most APIs have assumed that someone already created an account, got an API key and figured out billing. Cloudflare is experimenting with a different model: the request itself can carry the payment flow.
The current setup: Cloudflare's Monetization Gateway is in closed beta, initially uses USDC on Base through Coinbase's x402 Facilitator, and supports payments as low as $0.001 per request.
Why the old API billing model doesn't fit agents
Most APIs were designed around a known customer. Create an account, get an API key, choose a plan and start making requests.
That's fine when the person using the API is sitting there and knows what they want to buy.
An agent is different. It might discover a service halfway through a task and need it once. Or it might call the same service 200 times during one workflow.
Creating an account and buying a monthly plan just to make three API calls is a strange fit.
This is part of the broader shift toward what BlackRock's Digital Assets Research team describes as the "machine-native economy" — an environment where software can discover, consume and pay for resources without the traditional human checkout flow. We explored that idea in BlackRock’s “Machine-Native Economy”: Why AI Agents Will Need Machine-Native Payments.
| Traditional API | HTTP 402 |
|---|---|
| Create an account | Request the resource |
| Get an API key | Receive payment requirements |
| Prepay / subscribe | Pay for the request |
| Call the API | Retry with payment authorization |
| Billing happens separately | Payment is part of the HTTP flow |
One nuance is worth noting: while the x402 payment flow doesn't inherently require a traditional checkout or account flow, specific implementations can still enforce authentication. Cloudflare’s own AI Gateway machine-payment documentation, for example, currently still requires a Cloudflare account, an API token, and a card on file for that specific product. The architectural point is that the payment authorization itself moves inline with HTTP.
What happens when an agent hits a paid endpoint
Cloudflare's implementation uses the x402 protocol specification. When an agent requests a protected resource, the conversation follows a four-step sequence:
Agent Dispatches Request
The caller requests the resource over HTTP, optionally specifying supported payment methods.
Cloudflare returns the payment requirements
Cloudflare responds with HTTP 402 Payment Required and includes payment instructions—the cost, supported assets, recipient address, and facilitator details—in a payment-required header.
Agent Signs Authorization
The agent inspects the requirements, signs an authorization payload with its wallet, and retries the request with the payment authorization attached.
Payment is verified, then the request is fulfilled
The Gateway verifies the authorization, sends the verified payment context to the origin server, fulfills the request, and settles through Coinbase's x402 Facilitator.
Pricing doesn't always have to live at the edge
The interesting part is that pricing doesn't always have to live at the edge.
For simple endpoints, a seller can configure a static edge rule (for example, charging an exact $0.002 per call).
But many API workloads have variable costs. A search query might be cheap, while an LLM inference request depends on the exact number of tokens generated, and a PDF rendering job depends on compute and file size.
Cloudflare handles this by supporting two pricing schemes:
- Fixed pricing (
exact): The gateway advertises a fixed amount required to access the resource. - Variable pricing (
upto): The gateway informs the agent of the maximum price a request could cost. The origin reports actual consumption, and only the settled amount is charged.
With origin-controlled pricing, the edge gateway requests pricing information directly from the seller's existing pricing module. This prevents sellers from having to maintain two separate billing rules engines.
What agents can already buy
Cloudflare highlighted four customers testing this in production today:
Cloudflare AI Gateway (Inference)
Agents can pay for inference at request time for selected models instead of relying only on prepaid credits. Cloudflare specifically designed the Gateway to support origin-controlled pricing because AI Gateway already has its own pricing engine.
Ceramic.ai (Search)
Search becomes something an agent can buy when needed, rather than something tied to a fixed API-key quota. Ceramic says its index contains more than 40 billion pages and supports machine-oriented search with response times as low as 50 milliseconds.
That is probably the most important thing about these examples. The product isn't "crypto payments." The product is access to something an agent needs, with payment happening at the moment of use.
Stocktwits (Market Data)
Stocktwits is exposing market signals such as sentiment, message volume, and trending cashtags to agents on a per-request basis, while keeping its existing API and enterprise licensing products unchanged.
API2PDF (Utility APIs)
API2PDF uses variable pricing because the cost of a request depends on compute and bandwidth. Its old signup flow reportedly caused more than 50% conversion drop-off when requiring a credit card, according to the company. Agents can now pay a fraction of a cent per document instead of burning tokens trying to format complex PDFs directly.
Notice the pattern: None of these are selling "crypto." They're selling things agents already need — inference, search, market data and utility APIs. Payment is simply becoming part of the request.
What Cloudflare solves — and what it doesn't
Cloudflare makes the seller side considerably easier. But an HTTP 402 response still leaves the buyer with several decisions.
The agent has to understand the payment requirements, determine whether the resource is worth the price, check whether it is allowed to spend that amount, select a supported payment method, authorize the payment and retry the request.
And as more payment methods become available, that decision gets more complicated rather than less.
A payment protocol tells two machines how to pay. It doesn't necessarily tell an agent when it should pay.
Cloudflare is solving the seller side. The more interesting question for us is what happens on the buyer side.
A 402 response only helps if the agent can understand it, decide whether the request is worth paying for, choose an available payment method, authorize the payment and stay within whatever spending policy its owner has configured.
| Agent needs | Why it matters |
|---|---|
| Understand payment requirements | The agent has to know what it is being asked to pay before committing funds. |
| Decide whether to pay | Not every 402 response should be accepted. The agent has to evaluate task value against cost. |
| Compare payment options | The cheapest or fastest supported option may depend on the agent's current balances, limits and the endpoint's requirements. |
| Enforce spending policy | A single autonomous workflow could make hundreds of paid calls; it needs hard caps and allowlists. |
| Execute and verify payment | Payment has to happen cleanly without breaking the agent's reasoning loop. |
| Keep a record | Developers and finance teams need to know what the agent actually spent and why. |
This is where we're building at PayAgents.
The 402 protocol makes payment possible. We're interested in everything the agent has to do around that payment.
The routing problem
Today, Cloudflare's implementation uses Base and USDC through Coinbase's x402 Facilitator. But that's unlikely to be the only combination agents will encounter.
As more payment methods become available, an agent has another problem: which one should it use?
Cost, available balance, supported assets, latency and spending policy can all matter.
That's where payment starts looking less like a protocol problem and more like a routing problem.
For API providers, if an agent can discover your API but can't use it without a human creating an account and entering a card, you've created a payment bottleneck. HTTP 402 offers another option: expose the price as part of the request and let the caller decide whether to pay.
For agent developers, the opposite problem appears on the buyer side. Once paid APIs become normal, hardcoded API keys and manual billing won't scale across dozens of services. The agent needs a wallet, payment policies, and a way to handle different payment requirements without every tool implementing payments differently.
Cloudflare's launch doesn't mean agentic payments are solved. It means an important piece of internet infrastructure is making them easier to deploy.
The next problem is on the buyer side. If APIs can ask agents to pay at request time, agents need to decide what is worth paying for, how much they're allowed to spend, and which payment method to use.
That's the problem we're working on at PayAgents.