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 carrying the payment terms. 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.

How the x402 payment protocol works

The protocol extends HTTP's 402 Payment Required status code — a status first reserved in RFC 2068 in 1997 and still carried, unused, in the current HTTP spec, 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 PAYMENT-REQUIRED header carrying a base64-encoded PaymentRequired object: one entry per accepted requirement, each with the scheme, network, asset, amount, and payTo address.
3. Payment. The agent constructs an EIP-3009 transferWithAuthorization — a gasless, signature-based stablecoin transfer. The agent signs the authorization and attaches it to the PAYMENT-SIGNATURE header.
4. Delivery. The resource server passes the signed payload to a facilitator, which verifies the signature and submits the on-chain transfer. On success the resource server returns the resource, with a PAYMENT-RESPONSE header carrying the settlement receipt.

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

# Step 2: Server returns 402; terms travel in the PAYMENT-REQUIRED header
HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: <base64 PaymentRequired object>

# decoded PaymentRequired:
{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required",
  "resource": { "url": "https://merchant.example.com/api/market-data" },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "1000000",
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "payTo": "0xMerchant...",
      "maxTimeoutSeconds": 60,
      "extra": { "name": "USDC", "version": "2" }
    }
  ],
  "extensions": {}
}

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

# Step 4: Resource server verifies and settles via a facilitator, returns content
HTTP/1.1 200 OK
PAYMENT-RESPONSE: <base64 settlement receipt>
Content-Type: application/json
{ "data": "..." }

The cycle completes in two HTTP round-trips — the request that returns 402, and the retry that carries the signature — with no browser, no redirect, and no card form in between. The payment is embedded in the protocol the agent already speaks.

A practical detail: the header names changed with v2. Version 1 used X-PAYMENT; x402 v2, published 11 December 2025, removed the deprecated X-* headers in favour of PAYMENT-REQUIRED on the challenge, PAYMENT-SIGNATURE on the retry, and PAYMENT-RESPONSE on the settled reply. Implementations have converged on these, but a facilitator built before December 2025 may still emit X-PAYMENT — so read PAYMENT-SIGNATURE first and fall back to the legacy name, or you will silently lose traffic from clients on the other version.

What 100 million transactions reveal

Chainalysis published an analysis of x402 adoption in June 2026. Two data points stand out.

Value is migrating upward. In early 2025, payments above $1 accounted for 49% of x402 volume by value, and payments between 10¢ and $1 accounted for 46%. By early 2026, $1+ payments took 95% of volume and the 10¢–$1 tier had collapsed to 4% — though large numbers of sub-cent payments still flow through the protocol. These are shares of value, not of transaction count: the money is moving from experimental tips to commercial payments even as the long tail of micropayments continues.

Early growth was partly speculative. PING, a meme coin, used x402 as a pay-to-mint mechanism — users queried a URL, received a 402, and paid 1 USDC to mint. Chainalysis reports that weekly x402 transaction counts rose more than 10,000% off a near-zero mid-2025 base during the PING surge, with PING alone processing over 150,000 transactions in its first month. Growth moderated as speculative activity cooled; Chainalysis reads continued week-over-week wallet retention, absent any speculative catalyst, as a sign of ongoing utility.

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.

A further caveat on the headline count: a share of it may not be real traffic. Lucas Shin, an analyst at Artemis Analytics, built a filter for wallets that repeatedly transacted with themselves or cycled funds between addresses; applying it to a thirty-day window in early 2026 cut a reported $24 million to $1.6 million, according to a16z crypto (March 11, 2026). Treat any headline x402 count, including the one above, as an upper bound — we set the published figures side by side in why agentic payment volume numbers do not agree.

Where x402 is deployed

x402 started on Base with an implementation open-sourced by Coinbase in May 2025. Coinbase contributed the protocol to the Linux Foundation in 2026, and the canonical repository now lives at x402-foundation/x402; its second major version, x402 v2, shipped about seven months after the initial 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 launched a production x402 facilitator on mainnet in June 2026, which it claims makes it the first WebAssembly-native L1 to do so. Agents can query balances, submit transactions, read contract state, and monitor transfers through MCP tool surfaces; contract deployment runs through a separate toolchain.
• X Layer (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. Arc is a public testnet; mainnet has not launched.
• Kustodia launched smart-contract escrow on Arbitrum and Injective, exposed to agents through MCP tools, that wraps x402 payments in a trust layer — holding buyer funds until the programmatic release conditions are met or the paying agent verifies the deliverable.

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 payment terms, but it is not a commercial quote. There is no order context, no tax calculation, no shipping cost, no variant selection — just an amount, an asset, and a timeout.
• 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 an 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 — defines a trustless Job primitive for agent-to-agent commerce (escrowed payment, independent evaluation, on-chain settlement) and writes permanent on-chain receipts, and it recommends integrating with reputation registries such as 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 an 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.

Correction (2026-08-05): this post originally described the x402 v1 wire format. It showed an X-PAYMENT request header and a JSON 402 body with price/token/recipient/expires fields, and characterised PAYMENT-SIGNATURE as a Circle-specific variant. The reverse is true: x402 v2 (11 December 2025) removed the X-* headers and moved the payment terms into the PAYMENT-REQUIRED header, with PAYMENT-SIGNATURE on the retry. The protocol walkthrough, the code sample and the header paragraph have been rewritten against the v2 specification. We also corrected the round-trip count (two, not one), the facilitator's role (it settles; the resource server returns the resource), the repository's current home (the Linux Foundation's x402 Foundation, not Coinbase), the Chainalysis figures (shares of volume by value, not of transaction count), and the RFC in which 402 was first reserved (RFC 2068). Unsourced superlatives were removed.

Correction (2026-08-09): this post cited over 100 million x402 transactions on Base without noting that independent analysts have flagged a substantial share of x402 traffic as wash trading. Our house rule is that a disputed figure carries the dispute or comes out, and this one did neither. A caveat and a link to the fuller treatment have been added. The figure itself is unchanged and correctly sourced to Chainalysis.