x402 payment protocol explained: how agents pay over HTTP

x402 lets AI agents pay merchants over HTTP using stablecoin signatures. 100 million transactions on Base and counting. Here is how the protocol works and where it stops.

By XAgent Team · 2026-06-09

x402 is an HTTP-native payment protocol that lets AI agents pay for resources in the same request-response cycle they use to fetch data. An agent sends an HTTP request. The server returns a 402 Payment Required status with a price and a payment address. The agent signs a stablecoin transfer, resubmits the request with a payment header, and receives the resource. No checkout page. No redirect. No human. In under a year, this protocol has processed over 100 million transactions on Base alone — making x402 the highest-volume agent payment protocol deployed today.

How the x402 payment protocol works

The protocol extends HTTP's 402 Payment Required status code — a status that has existed in the HTTP spec since 1997 but was never widely used until agents needed a machine-readable way to pay for API calls, data, and services.

The flow has four steps:

1. Request. The agent sends a standard HTTP request to a resource — an API endpoint, a data feed, a service, or a product listing.
2. Challenge. The server returns 402 Payment Required with a JSON body: the price, the accepted token (typically USDC), the recipient address, the network, and an expiration timestamp.
3. Payment. The agent constructs an EIP-3009 transferWithAuthorization — a gasless, signature-based stablecoin transfer. The agent signs the authorization and attaches it to a payment header.
4. Delivery. A facilitator verifies the signature, submits the on-chain transfer, and returns the resource to the agent.

# Step 1: Agent requests a gated resource
GET /api/market-data HTTP/1.1
Host: merchant.example.com

# Step 2: Server returns 402 with payment terms
HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "price": "1000000",
  "token": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "network": "base",
  "recipient": "0xMerchant...",
  "expires": "2026-06-09T12:00:00Z"
}

# Step 3: Agent resubmits with signed payment envelope
GET /api/market-data HTTP/1.1
Host: merchant.example.com
X-PAYMENT: <EIP-3009 signed authorization>

# Step 4: Facilitator verifies, settles, returns content
HTTP/1.1 200 OK
Content-Type: application/json
{ "data": "..." }

The entire cycle completes in a single HTTP round-trip from the agent's perspective. No browser. No redirect. No card form. The payment is embedded in the protocol the agent already speaks.

A practical detail: the payment header has three variants in the wild. Coinbase's reference implementation uses X-PAYMENT. Circle CLI 0.0.3 ships Payment-Signature. Some SDKs send Authorization: Payment. A production facilitator needs to accept all three — spec drift is normal in a fast-forming protocol landscape.

What 100 million transactions reveal

Chainalysis — the leading blockchain analytics firm — published the first institutional analysis of x402 adoption in June 2026. Two data points stand out.

Transaction size is growing. In early 2025, 49% of x402 payments exceeded $1, and 46% fell in the 10¢–$1 range. By early 2026, $1+ transactions had climbed to 95%, and the micro-tier collapsed to 4%. The protocol is moving from experimental tips to commercial payments.

Early growth was partly speculative. PING, a meme coin, used x402 as a pay-to-mint mechanism — users paid 1 USDC via x402 to mint a token. PING generated over 150,000 transactions in its first month and a weekly volume spike above 10,000%. As speculative activity faded, volume settled to a lower but more sustainable baseline. Chainalysis described this as a transition from speculative to utility-driven usage.

The 100M number establishes x402 as the protocol with the most on-chain transaction volume in the agentic commerce category. But volume alone does not measure commercial depth. Most x402 transactions today are API-level micropayments — data access, model inference, gated content — not full e-commerce orders with inventory, shipping, and fulfillment.

Where x402 is deployed

x402 started on Base with Coinbase's open-source implementation, which shipped a second version six weeks after launch. Adoption has since spread across chains and use cases:

• Base remains the highest-volume chain, with USDC as the primary settlement token and the deepest facilitator ecosystem.
• Casper Network became the first WebAssembly-native L1 with a production x402 facilitator in June 2026. Agents can query balances, submit transactions, and deploy smart contracts through MCP tool surfaces.
• XLayer (OKX, Chain ID 196) supports x402 for USDG/USDT settlement via OKX OnchainOS.
• Arc Testnet (Circle, Chain ID 5042002) supports x402 for USDC via Circle Programmable Wallets.
• Kustodia launched MCP-native escrow contracts on Arbitrum and Injective that wrap x402 payments in a trust layer — locking buyer funds until delivery is confirmed by the counterparty.

The multi-chain expansion is a strength and a complication. Each chain has its own facilitator behavior, gas model, and finality guarantee. A merchant accepting x402 on more than one network needs to handle these differences — or delegate that work to an operations layer that does it for them.

What x402 does and does not solve

x402 is good at one thing: machine-to-machine payment inside an HTTP context. An agent pays for an API call, a data query, or a gated resource without leaving the request cycle. That is a clean, minimal design.

What x402 does not cover:

• Merchant discovery. x402 assumes the agent already knows the endpoint URL. The protocol has no registry, no catalog, and no way for an agent to find merchants that accept x402 payments.
• Binding quotes. The 402 challenge returns a price, but it is not a commercial quote. There is no order context, no tax calculation, no shipping cost, no variant selection — just a token amount and an expiration window.
• Authorization verification. x402 does not check whether the agent has permission to spend this amount on this category from this principal. Mandate enforcement lives outside the protocol.
• Order management. After payment, the resource arrives in the HTTP response body. For physical goods, subscriptions, or multi-step services, there is no order writeback, no fulfillment tracking, and no refund mechanism within the protocol itself.
• Full proof trail. The on-chain transfer provides settlement proof. It does not provide the complete audit trail — signed quote, authorization record, order ID, fulfillment state — that agentic commerce requires.

This is not a criticism. It is a description of scope. A payment protocol should not try to be a commerce platform. But a merchant who wants agents to buy real products — not just consume API endpoints — needs the operations layer that turns a x402 payment into a complete, provable transaction.

That is what the open execution market does. XAgent accepts x402 as one of several settlement paths. When an agent arrives speaking x402, the payment clears on whichever chain the merchant supports. When the next agent arrives via MCP tool call, a Visa tokenized credential, or another protocol, the execution layer handles that too. As we analyzed in our post on stablecoin settlement, more payment rails make the execution layer more valuable — not less.

The merchant ships one integration. The agent gets a quoted, authorized, settled, fulfilled, and provable transaction.

What's next

x402 will keep expanding. More chains will deploy facilitators. More agents will ship with x402-capable wallets. EIP-3009 transferWithAuthorization will remain the core signing primitive, but higher-level standards are forming on top. ERC-8183 — a draft Ethereum standard from Virtuals Protocol and the Ethereum Foundation — defines a trustless Job primitive for agent-to-agent commerce (escrowed payment, independent evaluation, on-chain settlement) and writes permanent on-chain receipts that feed reputation registries like ERC-8004. These add a verifiable proof layer above raw settlement.

For merchants, the protocol's growth changes the math. As agent-driven API and commerce traffic increases, the question shifts from "should I support x402?" to "how do I turn a x402 payment into a real order?" If that is your question, list your store on XAgent and let the execution layer handle the protocol, the rail, and the proof.