Definition

x402 is an open payment protocol that uses the HTTP 402 Payment Required status code to charge for a request. A server returns a 402 with a price, the client settles the amount, usually USDC on a chain like Base, and retries the same request with a payment header, which now succeeds. It lets software pay for a request per call with no account and no human.

Put plainly, x402 turns paying for something into a normal part of an HTTP request. Instead of signing up, entering a card, and checking out, a client simply asks for a resource, is told the price via a 402, pays, and asks again. That makes payment a native step in machine-to-machine communication, which is why it has become the common rail for autonomous agents paying for what they call.

Where the name comes from

The name comes from HTTP status code 402 Payment Required. This code was reserved in the HTTP specification decades ago but left largely unused, a placeholder for a future where requests could be paid for directly. x402 is the protocol that finally puts it to work, with the x a common convention for a protocol built on the code.

So x402 is, literally, a way of using 402 to ask for and settle payment for a request. When a server returns 402, it is saying this request requires payment, and x402 defines exactly how the price is quoted, how the client pays, and how it proves payment on the retry. That grounding in a standard HTTP status code is part of why x402 fits naturally into how software already communicates over the web.

How it works

The flow has three steps. First, a client requests a resource and the server responds with 402, including a body that describes the payment: a version, an accepts array listing the scheme (commonly exact-usdc), the amount in base units, the resource, and the pay-to details. Second, the client reads that, settles the amount in USDC, and builds a payment header. Third, it retries the same request with an X-Payment: exact-usdc:<base64> header, the server verifies the payment, and returns the resource.

In a typical implementation, helpers parse the 402 body and build the header, and the actual verification happens through a settlement step on the server side. With Blockchain0x, the client createX402Client handles the pay-and-retry automatically, and the server adapter handles returning the 402 and verifying. The point is that all of this happens in code, so a machine can complete the whole exchange without a human, which is what distinguishes x402 from a checkout flow.

A concrete example

It helps to see x402 with a concrete case. Imagine an AI agent that needs a current exchange rate from a paid data API. The agent requests the rate, and the API, instead of returning data, responds 402 with a body saying the call costs two cents in USDC, paid to a given address, on Base. The agent's x402 client reads that, settles two cents of USDC from the agent's wallet, and retries the request with the payment header attached.

The API verifies the payment and returns the rate, and the agent continues its task. From the agent's side, this looked like calling a tool that returned data; the payment happened inside. From the API's side, an unknown caller paid two cents and got served, with no account created. That single exchange, request, 402, settle, retry, succeed, is x402 in action, and it scales to an agent making hundreds of such calls to many services in a single task, each paid per call within the wallet's limit. That is the pattern the rest of this page describes in the abstract.

Why it suits AI agents

x402 suits AI agents because it removes the two things that block autonomous payment: signup and human approval. An agent that has never interacted with a service can pay for one call by settling the 402, with no account to create and no person to approve the charge. And because settlement is in a stablecoin on a low-fee chain, sub-cent and few-cent payments are economical, which matches the size and frequency of agent calls.

This is why x402 became central to agent payments. An autonomous agent paying for data, a tool, an MCP server, or another agent does so by speaking x402, settling each call within its wallet's spend limit. The protocol gives the agent a way to pay that fits how it works, in code, per call, at small amounts, against parties it does not know in advance. No prior payment rail offered that combination, which is the gap x402 fills for the agent economy.

What makes it open

x402 is an open protocol, co-created by Coinbase, and that openness is essential to what it is. Because the specification is open, anyone can build an implementation, and implementations that follow the spec interoperate: a client built on one can pay a server built on another, as long as both share a settlement scheme and network. So choosing an x402 implementation is closer to adopting a standard than locking into one vendor's system.

That matters for the agent economy, where agents from different builders on different platforms need to transact with each other. An open, interoperable payment protocol is what lets them, the same way open web standards let any browser talk to any server. x402 being open rather than proprietary is part of why it has spread as a shared rail rather than remaining one company's feature, and it is why a Blockchain0x agent and a Coinbase-based service can transact over it.

x402 versus traditional payment

x402 differs from traditional payment rails in being built for machines rather than humans. Where a card payment needs an account, a human, and carries fees that make micropayments uneconomic, an x402 payment settles a stablecoin per call with no signup, at sub-cent cost, and is final. Traditional rails keep their strengths for human commerce, broad acceptance and chargebacks, but they cannot serve the autonomous, per-call, micropayment workload x402 targets.

So the two are complementary rather than competing: x402 opens machine payments that traditional rails cannot serve, and traditional rails own human commerce x402 is not built for. The fuller treatment of that distinction lives in the comparison pages, but the short version is that x402 is the rail for software paying software, and that is a different job from a person paying a merchant.

Related terms

x402 connects to several related concepts. A stablecoin like USDC is what it settles in. An AI agent wallet is what holds the funds an agent uses to pay an x402 request. The X-Payment header and the accepts array are parts of the wire format. A server adapter is what gates a route to charge over x402, and a client is what pays. Agent-to-agent and machine-to-machine payment are the broader patterns x402 enables.

Understanding x402 is the foundation for those, because it is the protocol underneath them: the mechanism by which a machine pays for a request. To implement it directly, see how-to-implement-x402-protocol; for the wallet that funds x402 payments, see what-is-an-ai-agent-wallet. Pricing is on the pricing page.