What Is x402?
Last updated 2026-06-24
x402 is an open payment standard that lets software — including AI agents — pay for APIs and content directly over HTTP, using the long-dormant 402 "Payment Required" status code to settle stablecoin payments from a wallet instead of an API key.
Key takeaways
- ▸x402 turns the unused HTTP **402 "Payment Required"** status code into a working payment rail: a server can answer a request with "pay first," and the client pays inline.
- ▸Payments settle in stablecoins (USDC) from the agent's own [wallet](/wiki/how-agents-use-wallets) — no API key, no subscription, no human in the loop per call.
- ▸The standard is open and chain-flexible; live implementations settle on Base and Solana, with a facilitator/proxy verifying payment before content is served.
- ▸Adoption is real but early: 0x opened its Swap API to agents at **$0.01 per request** over x402, built on Alchemy's AgentPay ([The Defiant](https://thedefiant.io/news/defi/0x-swap-api-ai-agents-usdc-payment-x402)).
- ▸x402 is one contender, not the winner — it competes with Google's [Agent Payments Protocol](/resources/agent-payments-protocol-ap2) and Visa's Trusted Agent Protocol in an unsettled standards race.
x402 is an open payment standard that lets an AI agent pay for an API call over HTTP, settling in stablecoins like USDC straight from its own wallet — no account, no API key, no credit card. It revives the 402 "Payment Required" HTTP status code, a slot reserved in the original web spec but left unused for decades, and wires it to onchain settlement so a machine can pay for exactly what it uses, per request.
That shift matters because the web's payment layer was built for humans clicking checkout, not for onchain agents making thousands of small calls. x402 gives an agent a way to pay a server the way it already talks to one — over HTTP — and have the money move in the same round trip. This page covers what x402 is, how the request-and-pay flow works, who's actually shipping it, and where it sits in a crowded field of agent-payment standards. For the wider landscape, see how AI agents pay.
Why It Matters
An agent that can reason but can't pay is stuck asking a human to sign up, enter a card, and manage an API key for every service it needs. That breaks autonomy at the most basic level. x402 closes the gap by making payment a native part of the HTTP request an agent already makes — so it can discover a priced endpoint, pay per call, and move on, all without a pre-existing account. For builders, that means agents can buy data, compute, or other agents' services on demand, and providers can meter access by the request instead of by the seat. It's the difference between an agent that *talks about* paying for things and one that actually settles value on its own. See the [payments use case](/use-cases/payments) for where this plugs in.
How It Works
- ▸An agent (the HTTP client) requests a protected resource — say, a market-data or swap-quote endpoint — with no payment attached.
- ▸The server responds with **HTTP 402 Payment Required**, including machine-readable payment details: how much, in which token, on which chain, and to which address.
- ▸The agent's wallet constructs and signs a stablecoin (USDC) payment authorization matching those terms, and retries the request with the payment in an HTTP header.
- ▸A facilitator (a proxy/verifier) checks the signed payment against the requirements and settles it onchain — implementations run on Base and Solana.
- ▸Once payment verifies, the server returns the actual content or API response, completing the request in the same exchange the agent started.
- ▸Metered per call, the agent pays only for what it uses — a $0.01 quote costs $0.01, not a monthly plan.
Key Components
- •The HTTP 402 "Payment Required" status code (the trigger)
- •A machine-readable payment-requirements payload (amount, asset, chain, recipient)
- •An agent-controlled wallet that can sign payment authorizations
- •A stablecoin for settlement (USDC is the common default)
- •A facilitator / proxy that verifies and settles the payment
- •A supported settlement chain (Base, Solana in current implementations)
- •The provider's priced endpoint (the API or content being sold)
Reviving HTTP 402: the status code that waited 30 years
Every web developer has met 404 Not Found and 403 Forbidden. Far fewer have ever seen `402 Payment Required` — because for most of the web's history it did nothing. The code was reserved in the early HTTP spec as a placeholder for some future digital-payment system that never standardized, so browsers and servers simply never used it.
x402 fills that empty slot. When a server wants payment for a resource, it answers with 402 plus a structured description of what payment it expects. The client reads those terms, pays, and retries. Nothing about the underlying web changes — no new ports, no new protocol — which is the point: an agent that already speaks HTTP can pay without learning a separate payment API. The standard and its reference implementation are documented at x402.org.
The pay-per-request flow, step by step
Concretely, here's what a single paid call looks like for an agent:
- Ask. The agent sends a normal request to a priced endpoint.
- Get quoted. The server returns
402with the price (e.g.0.01 USDC), the chain, and the destination address. - Pay. The agent's wallet signs a USDC payment authorization for exactly that amount and resends the request, carrying the signed payment in a header.
- Verify. A facilitator validates the signature and settles the payment onchain.
- Receive. The server returns the data.
The whole thing happens machine-to-machine, with no human approving the charge and no API key provisioned in advance. Settlement uses stablecoins so the amount is predictable, and current implementations run on Base and Solana, where low fees make sub-cent payments practical. This is why x402 is often described as a rail for micropayments — paying fractions of a cent per call only works when the settlement cost is also tiny. Alchemy's writeup walks through the mechanics in more depth (Alchemy).
Who's actually using it
Adoption is early, but it's not a whitepaper-only standard. The clearest live example: 0x opened its Swap API to AI agents at $0.01 per request, paid in USDC over x402 — built on Alchemy's AgentPay — so an agent can pull swap quotes without an account or key, paying as it goes (The Defiant). That's a real provider metering a real API by the call.
A caveat, per SatoHub's evidence rule. "Adoption" here means *integrations that exist*, not proof that high payment volume is flowing through them — the standard is young, and most usage figures are self-reported. Treat live integrations as shown, and broad "everyone's using x402" claims as claimed until the on-chain volume backs them. For more SatoHub-tracked tooling around this, see Alchemy in the directory and the x402 resource page.
x402 vs. AP2 vs. Visa's Trusted Agent Protocol
x402 isn't the only proposal for how agents pay. It sits in a three-way standards contest, with no winner yet:
- ▸x402 (open, crypto-native): pay per HTTP request in stablecoins from a wallet. Strong fit for agent-to-API micropayments. Covered on the x402 resource page.
- ▸Agent Payments Protocol (AP2) — Google-led, with a broad partner set, aimed at giving agents a verifiable mandate to transact across payment types including cards and crypto. See AP2 in the directory.
- ▸Visa Trusted Agent Protocol (TAP) — a card-network approach focused on letting trusted agents transact within existing rails.
The useful read: x402 optimizes for permissionless, per-call payments between software, while the card-network and big-platform efforts optimize for identity, mandates, and fitting agents into existing rails. They may end up complementary, not mutually exclusive. The how AI agents pay page maps all three. Whatever wins, the agent still needs a wallet that can sign safely.
Examples
- ▸0x's Swap API priced at $0.01 per request in USDC over x402, so an agent can fetch quotes with no API key (built on Alchemy AgentPay).
- ▸A data agent paying a few cents per call to a metered market-data endpoint instead of buying a monthly subscription.
- ▸An agent buying another agent's output — e.g. a research summary — settling the micropayment inline over HTTP.
- ▸A content API gating premium responses behind a 402, letting machine clients pay per fetch rather than registering accounts.
- ▸An infrastructure provider metering RPC or compute access per request, settling in USDC on Base.
Risks & Limitations
- ⚠Standards risk: x402, AP2, and Visa's TAP are competing, and which becomes dominant is unsettled — building on one is a bet, not a sure thing.
- ⚠Adoption is early; most usage and volume figures are self-reported, so live integrations are shown but scale claims are still claimed.
- ⚠Wallet and key exposure: an agent paying autonomously needs tight spend limits and scoped permissions, or a bug/prompt injection can drain funds per call.
- ⚠Settlement assumptions: per-request payments only stay cheap on low-fee chains, and depend on the facilitator/proxy behaving honestly and staying available.
Frequently Asked Questions
- What is x402 in simple terms?
x402 is an open standard that lets software pay for things over HTTP. When a client requests a paid resource, the server replies with the
402 Payment Requiredstatus code and the price; the client pays in stablecoins (USDC) from its wallet and retries, and the server returns the content. It's designed so an AI agent can pay for an API call without an account or API key.- How does x402 actually move money?
The agent's wallet signs a USDC payment authorization matching the server's stated terms — amount, token, chain, and recipient — and sends it back in an HTTP header. A facilitator (proxy) verifies the signed payment and settles it onchain before the server serves the content. Current implementations settle on Base and Solana, where low fees make sub-cent payments practical.
- Who is using x402 today?
Adoption is early but real. The clearest example is 0x opening its Swap API to AI agents at $0.01 per request in USDC over x402, built on Alchemy's AgentPay (The Defiant). Treat live integrations as evidence of the standard working; broad volume or "widely adopted" claims are still mostly self-reported.
- How is x402 different from Google's AP2 or Visa's Trusted Agent Protocol?
x402 is open and crypto-native, optimized for per-request stablecoin payments between software. Google's Agent Payments Protocol (AP2) and Visa's Trusted Agent Protocol focus more on mandates, identity, and fitting agents into existing card rails. They're competing standards, and none has won yet — see how AI agents pay for the full comparison.
- Is x402 safe to use for autonomous payments?
x402 defines how payment happens, not how to bound risk — that's on the wallet setup. An agent paying autonomously should use spend limits, scoped permissions, and policy-controlled signing so a single bug or prompt injection can't drain it. Treat any "safe" or "verified" framing as a claim until the wallet controls and on-chain behavior show it. See how agents use wallets.
Sources
Related Resources
x402
EarlyOpen payment protocol enabling agents and apps to pay for APIs over HTTP using stablecoins.
Alchemy
ActiveA blockchain developer platform providing node infrastructure plus NFT, Token, and Transfers APIs and SDKs across many chains.
Coinbase AgentKit
ActiveCoinbase's toolkit for giving AI agents wallets and the ability to take onchain actions.
Agent Payments Protocol (AP2)
ActiveOpen protocol from Google for secure agent-led payments across traditional and crypto rails, with a crypto-native x402 extension built with Coinbase, Ethereum Foundation, and MetaMask.
Related Wiki Pages
Join the Sato Hub Briefing
One email a week — the agents, tools, and infrastructure that actually shipped, and why they matter.