x402 is an open payment protocol that lets an AI agent or app pay for a web resource inside the normal HTTP request cycle. The server answers with 402 Payment Required and a machine-readable price; the client signs a stablecoin payment, usually in USDC, and retries the same request with that payment attached. No account, subscription or API key is required. This guide reflects the x402 v2 specification, Coinbase and Cloudflare developer documentation, the Linux Foundation announcement and published security research as of October 2026. It explains the protocol; it does not evaluate any token or forecast prices.

What is x402? An open protocol built on HTTP 402

HTTP 402 has been reserved for payments for decades, but without a standard format almost nobody used it. The x402 documentation describes reviving the code to tell a client that payment is required, communicate the amount, currency and destination, and give the client everything it needs to pay programmatically. The target use cases are machine-to-machine payments, pay-per-call APIs and paywalled content, and micropayments that would be impractical with card fees and account sign-ups.

Coinbase created x402 and later contributed it to a neutral home. According to the Linux Foundation, the x402 Foundation announced its intent to launch in April 2026 and became fully operational on July 14, 2026, when Coinbase completed the contribution. At that point 40 organizations had joined. Premier members include AWS, American Express, Circle, Cloudflare, Coinbase, Google, Mastercard, Shopify, Stripe and Visa. Membership signals support for the standard; it does not mean every member already accepts x402 payments in its own products.

The x402 v2 specification separates three layers: the data types (payment requirements, payment payload, settlement response), the scheme logic that depends on the payment method and network, and the transport that carries messages, such as HTTP, the Model Context Protocol (MCP) or agent-to-agent (A2A) messaging. That is why the same idea can price an HTTP endpoint or an individual MCP tool call.

How an x402 payment works, step by step

Three parties are involved: the resource server (the seller), the client (an app or AI agent) and an optional facilitator that verifies payments and settles them onchain. Cloudflare's Agents documentation describes the facilitator as optional but recommended, and notes that it does not hold funds: it checks and broadcasts a transaction the client has already signed.

1. 1

   The client requests a resource

   The agent sends an ordinary request, for example GET /resource. If it already knows the payment terms it can attach payment on the first try.

2. 2

   The server replies with 402 and PAYMENT-REQUIRED

   The header carries Base64-encoded JSON listing accepted payment options: scheme, a CAIP-2 network ID, the amount in atomic token units, the asset address, the payTo recipient and a timeout.

3. 3

   The client signs and retries

   The wallet picks one option, signs a payment authorization and resends the request with a PAYMENT-SIGNATURE header. For the exact scheme on EVM chains this is an EIP-3009 authorization with a 32-byte nonce and validity window to block replays.

4. 4

   The server verifies before doing the work

   The server calls the facilitator's /verify endpoint, which the spec defines as read-only. If verification fails, the client gets another 402.

5. 5

   Settlement and PAYMENT-RESPONSE

   The server or facilitator submits the payment through /settle. On success the client receives 200 OK plus a PAYMENT-RESPONSE header with the transaction hash.

Two details trip people up. First, amounts are atomic units: the spec's example value of 10000 equals 0.01 USDC because USDC uses six decimals. Second, timing varies. The default authorization flow runs verify, then the resource, then settle, so funds move only after the work completes. Other flows, called upfront and escrow, commit funds before the resource runs. When a server offers both, the spec says clients should prefer authorization.

x402 vs API keys and card billing

Most paid APIs today require sign-up, a card on file and an API key, with usage billed monthly. x402 swaps identity and billing for a signed payment on each request or batch. The comparison below shows what changes for a developer or agent operator.

The last two rows matter most. Card networks add limits and fraud monitoring by default, while the x402 specification explicitly lists client-side budget management as out of scope. Paying without an account is also not the same as paying anonymously: reusing one wallet across services can link activity onchain. If you follow the AI agent and stablecoin conversation, the theddari Telegram trend pages collect what crypto and AI channels are discussing; treat those as early signals to check against primary documentation.

页面引用

趋势theddari.com›趋势Telegram · 加密货币加密货币频道实时帖子

页面引用

趋势theddari.com›趋势Telegram · AIAI 频道实时帖子

Schemes, networks and facilitator fees

A scheme defines how a payment is built and settled. Cloudflare's docs describe exact as a fixed token transfer to the merchant and upto as authorizing a maximum, with the final charge based on actual consumption. The x402 docs add batch-settlement, which confirms the authorization up front and redeems value onchain later in bulk.

Check support at the source

Documentation can lag. Cloudflare lists upto as EVM-only, while Coinbase's CDP Facilitator page lists exact and upto on Solana too, alongside Base, Polygon, Arbitrum, Monad and World. Coinbase recommends treating the facilitator's supported-networks endpoint as the source of truth, and the spec defines GET /supported for exactly that purpose.

Facilitator pricing is a seller cost

As of October 2026, the CDP Facilitator charges nothing for the first 1,000 onchain transactions each month and $0.001 per onchain transaction after that. Verification is free, and fees follow onchain activity rather than payment requests, so batch-settlement can spread one transaction across many payments. Coinbase also says the service has processed more than 100 million transactions and $28 million in payment volume across Base and Solana, and screens payments against OFAC and Know Your Transaction checks. Those figures describe Coinbase's own facilitator, not the whole x402 market.

The risks: overspending, malicious 402s and facilitator flaws

Removing payment friction also removes a natural brake. When no human clicks confirm, a small mistake can repeat many times before anyone notices.

Buyer-side risks

• Runaway spending: with no budget layer in the spec, a retry loop or bug can keep paying small amounts.
• Malicious or tampered 402 responses: a server can quote an inflated price or a different payTo address, and an agent that trusts the header will sign it. Prompt injection from a web page that steers an agent toward a paid endpoint belongs in the same category.
• Metadata leakage: the resource URL and description reach the seller and facilitator, so identifiers embedded in URLs can expose personal data.
• Misreading settlement_pending: the spec defines this as a non-terminal state where a transaction was broadcast but not confirmed. Retrying blindly can double-pay; reconcile the transaction hash first.

Seller and facilitator risks

Facilitators are shared infrastructure, so one flaw can affect many merchants at once. A USENIX Security 2026 paper tested 15 major facilitators used by more than 60,000 sellers and 360,000 buyers and found violations in all of them. The authors describe four attack classes, Free Shopping, Asset Theft, Service Denial and Gas Abuse, and report that affected parties, including Coinbase, adopted mitigations after disclosure.

Operational and regulatory risks

Stablecoin settlements are hard to reverse, and they carry the issuer and depeg risks of the stablecoin itself. Rules on stablecoin payments, sales tax and income reporting differ by country and state. An open protocol does not make a use case compliant in your jurisdiction, so check local guidance before accepting or sending payments at scale.

Checklist before giving an agent an x402 wallet

1. 1

   Prototype on a testnet

   Run the full loop on a testnet such as Base Sepolia with test USDC, and confirm your atomic-unit conversion.

2. 2

   Isolate the wallet

   Use a dedicated agent wallet funded only with an amount you can afford to lose, and keep the signing key out of the agent's direct reach.

3. 3

   Enforce caps and allowlists before signing

   Check a per-payment cap, a daily total and approved domains and payTo addresses, and block repeated payments to the same resource in a short window.

4. 4

   Require human approval for new payees

   Route first-time recipients and unusually large amounts to a person. Cloudflare's examples show payments configured with or without human confirmation.

5. 5

   Log and reconcile

   Record the transaction hash, amount and recipient for every payment and compare them with onchain data on a schedule.

x402's simple handshake, ask for a price in the HTTP response and pay with a signature, could become a common language for AI agent payments. That same simplicity means the guardrails are not included by default. Build spending limits, recipient checks and logging first, then connect small amounts. To see how x402 discussion develops across blogs and communities, the theddari blog trend dashboard is a useful starting point.

页面引用

趋势theddari.com›趋势博客仪表盘Naver 博客活跃度排行