What Is x402? The Protocol That Makes HTTP 402 Payment Required Real

The history of HTTP 402 Payment Required

HTTP 402 was reserved in the original HTTP/1.1 specification published in 1997. The authors anticipated that the web would eventually need a native payment status code, but no standard protocol emerged to define what a client should do when it received one. For nearly three decades, 402 sat unused in production while workarounds like OAuth tokens, API key dashboards, and Stripe checkout pages filled the gap.

x402 finally gives 402 a concrete protocol definition. When a server returns a 402 response, it includes structured payment terms: the price, the accepted currency (USDC), the destination address, and the supported settlement chains. The client knows exactly what to pay, where to pay, and how to prove it.

How the x402 handshake works in a single HTTP round-trip

The flow has four steps. First, the AI agent sends a standard HTTP request to a paid endpoint. Second, the server responds with HTTP 402 Payment Required and a JSON body containing the price, the payee wallet address, and the accepted chain (for example, Base). Third, the agent's wallet signs a USDC transfer for the specified amount and the agent retries the original request with an X-Payment header containing the signed transaction. Fourth, the server verifies and settles the payment on-chain, then returns the requested resource with an HTTP 200.

This entire exchange completes in a single logical round-trip. There is no redirect to a checkout page, no OAuth dance, and no need for the agent to hold vendor-specific API keys. The payment is the authentication. Developers building agents that call paid APIs can learn more about the broader landscape in our guide to payments for AI agents (/learn/payments-for-ai-agents).

Why x402 matters in 2026: autonomous agents need to spend money

AI agents built on frameworks like Claude, Cursor, and Claude-Code increasingly run multi-step tasks that require calling external APIs. Some of those APIs are free, but many of the most valuable ones, weather data, legal databases, financial feeds, charge per request. Before x402, an agent either needed a developer to pre-register and embed API keys for every provider, or it simply could not access paid services.

x402 flips this model. An agent with a funded USDC wallet can discover payment terms at request time and pay on the spot. This is especially important for autonomous workflows where the agent decides which APIs to call based on the task, not based on which keys it was given. The economics work at small scale too: per-call pricing through x402 often falls in the micropayment range, a topic covered in depth in our API micropayments guide (/learn/api-micropayments).

What x402 replaces: API keys, subscriptions, and billing dashboards

Traditional paid API access requires a developer to sign up on each provider's site, enter a credit card, generate an API key, and embed that key in the agent's environment. Each new provider means another account, another billing relationship, and another key to rotate and secure.

x402 collapses all of this into a single wallet balance. The agent does not need per-vendor credentials because the payment itself authorizes the request. Providers do not need to build billing dashboards because settlement happens on-chain in USDC. For developers, this means one funding step instead of N vendor onboarding flows.

How MCP servers integrate x402 for tool-calling agents

The Model Context Protocol (MCP) defines how AI agents discover and invoke external tools. An MCP server can wrap any x402-protected API as a tool, exposing it to agents that support MCP tool calls. When the agent invokes the tool, the MCP server handles the 402 handshake transparently: it receives the 402 response, signs the payment from the agent's wallet, and retries the request.

This means agent developers do not need to write custom payment logic for each API. The MCP server acts as a payment-aware proxy. AgentCash provides exactly this kind of MCP server, installable into coding agents like Cursor and Claude-Code. For a deeper look at how payment flows integrate with MCP, see the MCP payments pillar (/learn/mcp-payments).

How AgentCash implements the x402 client and router roles

AgentCash serves two roles in the x402 ecosystem. As a client, it provides the AI-agent wallet that signs USDC payments when a 402 response is received. As a router, it maintains an index of x402-protected endpoints so agents can discover paid APIs without manual configuration. AgentCash currently indexes 1 payment-protected origin spanning 1 API category, with 30 priced endpoints and a median observed price of $0.028 per call (range: $0.002 to $0.440, as of 2026-04-07).

Developers get started by running npx agentcash from the CLI, which creates a wallet and connects the MCP server to their coding agent. From there, they fund the wallet with USDC on Base, Solana, or Tempo and begin calling any indexed endpoint. One balance covers every provider; there is no per-vendor signup.

Tradeoffs and current limitations of x402

x402 requires the server to support the protocol. If an API provider has not implemented 402 responses with structured payment terms, the agent cannot pay via x402 and must fall back to traditional API key access. Adoption is still early, with the number of payment-protected origins growing but not yet covering every API category.

Settlement finality depends on the underlying chain. On Base, transactions typically confirm within a few seconds. On Solana, confirmation is sub-second in most cases. Developers should be aware that network congestion can occasionally increase settlement latency, though L2 and high-throughput chains keep this rare in practice.

Another consideration is spend control. Because agents can pay autonomously, developers need to set spending caps to prevent runaway costs. AgentCash addresses this through wallet-level controls configured at setup time.