What Is the x402 Protocol? HTTP 402 and Machine-Native Payments Explained

Last updated: 2026-06-07

x402 takes a status code that has sat unused since the 1990s, HTTP 402 ("Payment Required"), and turns it into a way for software to pay software. An agent calls a paid tool. The server answers 402 with a machine-readable payment request. The agent pays, gets a cryptographic receipt, and continues, no checkout page, no human. It's the cleanest mechanism yet for letting an agent pay for something inside its own reasoning loop.

Key takeaways

HTTP 402 was reserved "for future use" in the HTTP/1.1 spec (RFC 2068, 1997) and never got one. x402 is the first serious attempt to actually use it.
The server returns "payment required" as structured data an agent can resolve on its own, no redirect to a human payment page.
Coinbase's implementation settles in USDC on Base (its Ethereum L2): fees a fraction of a cent, payments that confirm in about two seconds.
One extra round-trip, no human in the loop, a tamper-proof on-chain receipt as proof.
x402 moves the money. It says nothing about who set the budget, what the policy is, or whether this agent should have spent at all. That's a separate layer.

Why did HTTP 402 sit unused for three decades?

The code entered the HTTP spec reserved "for future use" (formalized in HTTP/1.1, RFC 2068, in 1997), the assumption being that the web would eventually need payments baked into the protocol. It never happened. Money moved through forms, redirects, and human checkout. Banks didn't expose programmatic APIs. You couldn't finish a payment in a single round-trip, so 402 sat idle for nearly three decades.

What changed is settlement. With a stablecoin like USDC on a fast L2, you can move money to anyone with a wallet address and have it confirmed in about two seconds. Suddenly a one-round-trip machine payment is real. x402 is built for exactly that world, which is also why it's wedded to crypto rails, a point worth holding onto.

How does x402 actually work?

Four steps:

An agent (or any HTTP client) requests a paid resource, an API, a tool call, a data feed.
The server returns HTTP 402 with a payment payload: amount, accepted token (e.g. USDC), recipient address, chain, expiry.
The agent reads the 402, signs an on-chain transaction, and re-sends the original request with a payment-proof header.
The server verifies the payment, serves the resource, and hands back a receipt.

One extra round-trip. No redirect, no checkout page, no OAuth dance. The agent hits a price and pays it.

Coinbase's version settles USDC on Base. An orchestrator in Frankfurt can pay a tool in Tokyo without touching a bank or card network, and without the multi-day settlement and FX drag that card rails carry. That's the genuine advantage, and it's not small.

Why does x402 fit AI agents so well?

Three reasons.

It's synchronous with how an agent thinks. Tool calls return results; x402 makes "payment required" just another result with a defined resolution. The agent hits a price mid-task and clears it without breaking flow, no human redirect, no pre-provisioned credential.

The receipt is cryptographic. An on-chain transaction hash is tamper-proof and anyone can verify it: operator, auditor, dispute process. Better evidence than a receipt email.

Micropayments actually work. Card transactions have floor costs that make sub-dollar charges pointless. Near-zero on-chain fees make $0.003 per call or $0.12 per lookup viable, pricing that legacy rails simply can't do.

What does x402 leave open?

x402 is clean at the payment-and-settlement layer. Above that, it's silent.

Who authorized the spend? It assumes the agent has a funded wallet. It doesn't ask whether a human delegated that authority, whether policy allows this category, or whether the charge fits the budget for this task.

What stops a bad payment? There's no concept of merchant-category limits, per-agent caps, or approvals. A funded agent can pay any 402-returning endpoint with nothing between it and the resource.

How does it show up in your books? On-chain transactions are pseudonymous. Tying a USDC payment back to a specific agent, task, and cost center takes infrastructure x402 doesn't provide.

Those are control-plane questions. As covered in what are AI agent payments, the split between moving money and governing it is the whole game: x402 nails one side and leaves the other untouched. At any real scale, the governing side isn't optional.

Is x402 a formal standard yet?

Not an IETF or W3C standard, but it's no longer a single-vendor project either. Coinbase launched x402 in May 2025, announced the x402 Foundation with Cloudflare in September 2025, and the protocol moved under the Linux Foundation in April 2026, with Google, Microsoft, AWS, Visa, and Mastercard among the early participants. It still leans on the original 402 code by convention, not formal extension.

Neutral governance lowers the splinter risk that hangs over any single-vendor protocol. The core pattern, 402 plus a machine-readable request plus on-chain settlement plus a signed receipt, is sound enough that some version sticks around. What's still open is formal standardization: the spec lives with the x402 Foundation, not a standards body, so check version compatibility before you build against one implementation.

Frequently asked questions

What does HTTP 402 mean? It's the HTTP status code for "Payment Required." It was reserved for future use in the HTTP/1.1 spec in 1997 and never tied to a specific mechanism. x402 is the first serious standard built on it, using on-chain stablecoin settlement to deliver the original intent.

What is Coinbase's x402? An open-source implementation that lets endpoints request USDC payment on Base. When a client hits a paid endpoint and gets a 402, the x402 client builds an on-chain payment and retries with a payment header. Payments confirm in about two seconds.

Can AI agents use x402 inside MCP tool calls? Yes. An MCP server can answer a tool call with a 402 payment response; an agent whose runtime supports x402 resolves it and retries. Tool builders can charge per call without managing subscriptions or API keys.

Does x402 replace virtual cards for agent payments? No, different problems. x402 settles on-chain; virtual cards run on Visa/Mastercard rails. Plenty of vendors take cards but not stablecoins, and vice versa. A full stack may use both, with a control layer enforcing policy across each.

What are the open control questions with x402? It doesn't specify who authorized the spend, what the budget is, or whether the agent should buy this at all. Deploy agents on x402 and you still need a separate policy layer, otherwise any funded agent can pay any 402 endpoint with no oversight.

For where x402 sits relative to MCP, AP2, and Visa TAP, read the agentic payments stack explained.