Skip to content
A global perspective on digital financeAbout The Token Press
CRYPTO. FINANCE. WHAT’S NEXT.The Token PressYour daily briefing ↗

Beginner · 6 min read

What Is x402? Coinbase, Cloudflare and AI Payments Explained

Understand x402 payments, Coinbase and Cloudflare’s roles, Google AP2, and how an AI agent pays for an API—with a worked budget and safety checks.

The Token Press education desk · Updated

Four stages of an x402 request: ask, receive terms, authorize, then verify payment and deliver the result.
Original payment-flow diagram. The example is illustrative; settlement timing depends on the chosen scheme.

What x402 actually does

x402 is an open payment protocol for web resources such as API responses and datasets. A server can reply with HTTP 402 Payment Required, describing the terms under which it will provide the resource. A compatible client can inspect those terms, authorize payment and retry. The protocol is useful when software needs to buy a small amount of a service during a task.

Think of an assistant preparing a shipping estimate. It may need one paid address-validation result rather than a monthly subscription. x402 describes the payment interaction; the seller still has to provide a useful result. A successful payment does not establish that the data is accurate, licensed for your purpose or worth buying.

Coinbase, Cloudflare and Google: who does what?

Coinbase started the work on x402. On September 23, 2025, Coinbase announced its intention to create the x402 Foundation with Cloudflare. That dated announcement describes their governance and interoperability ambitions; it should not be read as a guarantee that every company product accepts x402.

Cloudflare separately announced x402 support in its Agents SDK and MCP integrations. Its September 30, 2026 Monetization Gateway announcement described a closed beta for eligible U.S.-based sellers and buyers, with settlement through Coinbase’s facilitator using USDC on Base. Cloudflare identified AI Gateway, Ceramic.ai, Stocktwits and API2PDF use cases. These are provider-reported deployments, not an independent audit of transaction volume.

Google’s September 16, 2025 AP2 announcement described an A2A x402 extension developed with Coinbase, the Ethereum Foundation, MetaMask and others for agent crypto payments. AP2 addresses authorization and trust in agent-led commerce; x402 addresses payment exchanges for resources over HTTP. They are related components, not interchangeable names. Participation in AP2 alone does not prove a company runs an x402 service.

Follow one payment from request to result

Imagine a fictional API selling a delivery-zone lookup for 0.01 USDC. Your assistant requests a result. The server returns its price, accepted network, token and recipient. Your payment policy checks these against an allowed list and your remaining budget. Only then should the client sign the necessary authorization.

The seller checks the authorization, optionally through a facilitator, and handles settlement according to the supported scheme. It returns the resource when its payment conditions are satisfied. Keep the result and payment status together so a later timeout can be investigated. Signing, verifying, settling and delivering are different events; record each one.

A facilitator helps verify and settle payments. It is optional, and the protocol’s facilitator role is not custody of the buyer’s funds. You still need to evaluate a provider’s network support, availability and operational terms.

The same protocol can support different payment arrangements

Do not assume every x402 service uses the same blockchain, token or timing. Compatibility involves the client, server, facilitator, payment scheme and network. The current documentation uses unambiguous network identifiers, including eip155:8453 for Base. A familiar token symbol by itself is insufficient: the chain and token identifier matter.

The V2 documentation distinguishes immediate settlement flows from batch settlement, where an authorization can be accepted before later onchain redemption. An authorization receipt therefore should not automatically be described as final settlement. Check which scheme a service actually offers before connecting a budget to it.

Work out a small agent budget

Here is an illustrative budget, not a provider quote. At 0.01 USDC per lookup, 100 lookups cost 1 USDC and 1,000 cost 10 USDC. A 5 USDC daily service-payment budget buys at most 500 such lookups before any other costs. Token quantities are not a promise of a fixed fiat redemption value.

Now allow at most two paid attempts per job. One hundred jobs can require up to 200 paid attempts, or 2 USDC, if every retry becomes a separately authorized purchase. Proper retry handling may avoid duplicate charges for the same operation, but do not assume it is automatic. Reserve budget for requests already in flight, so ten simultaneous jobs cannot all spend the same remaining allowance.

The advertised resource price is only one cost. Ask who pays network fees, whether the facilitator charges, and whether wallet funding, conversion or your AI model adds costs. Compare total cost per usable result with a subscription or prepaid API rather than comparing headline transaction fees alone.

x402, X Pay and other similar names

x402 is the protocol. X Pay is one service name in the wider payments market; it is not another name for x402, Coinbase or Cloudflare. Likewise, an article about a similarly named wallet, social platform or token does not establish a relationship. Verify the official domain, operator and integration before treating two announcements as the same project.

You do not need to buy a speculative “x402 token” merely to understand the protocol. An actual service specifies its accepted payment asset. Any investment pitch using the protocol’s name needs separate evidence and should not be confused with technical adoption.

A five-minute buyer safety check

Write a policy before giving an agent a payment tool. Start with a small dedicated test budget, a known seller and a route you can inspect. Keep treasury funds separate. A prompt saying “spend carefully” is weaker than limits enforced by the payment system.

  • Verify the seller domain, resource, full recipient, network and token identifier.
  • Cap the amount per request, per job and per day; count concurrent requests and retries.
  • Reject an unexpected price or destination instead of silently signing new terms.
  • Confirm what happens when payment succeeds but the resource fails to arrive.
  • Record the authorization, settlement status and delivered result; never log a private key.
  • Check refunds, data rights and service support separately from protocol compatibility.

Sources & further reading

Educational content. Examples are illustrative. Protocols, products and rules can change; consult the linked documentation for current details.

Explore the newsroom

Connect what you have learned with the latest reporting.