What is x402?
x402 is a way for software to pay software over HTTP, with no account, no subscription and no checkout page. The name comes from the status code it revives: 402 Payment Required, reserved in the original HTTP specification and left unimplemented for roughly thirty years because nobody had a payment method a machine could complete on its own. Stablecoins gave it one. The official description on x402.org calls it an "open, neutral standard for internet-native payments" that "absolves the Internet's original sin by natively making payments possible between clients and servers." In practice it means an AI agent can hit a paid API it has never seen before, read the price out of the error response, pay it, and get the data back, all inside a couple of round trips. The protocol is deliberately thin. It describes how to advertise a price and how to carry proof of payment. It does not run your business logic, hold your money, or decide whether a purchase was a good idea.
What is HTTP 402 Payment Required?
402 Payment Required is a client error status code in the 4xx family, set aside in the HTTP standard for exactly this purpose and then never standardized further. For decades the specification effectively said the code was reserved for future use, so servers that wanted to charge for something redirected you to a billing page or returned 401 or 403 instead. That is why the 402 status code is the one most developers have read about but never actually received. If you are hitting a 402 today from an ordinary API, it usually means an account is out of credit or a payment method failed, and each vendor invented its own meaning. x402 is the first serious attempt to give the code a shared, machine-readable contract: a 402 response is no longer a dead end but a quote, structured well enough that a program can act on it without a human reading the docs.
How does x402 work, step by step?
Coinbase documents the flow in nine steps, and every implementation follows the same shape. One, the client requests a protected resource with an ordinary HTTP request. Two, the server answers 402 with a JSON body describing what it will accept: price, recipient, network and asset. Three, the client picks one of the offered options, signs a payment authorization, and resends the identical request with the signed payload in a header. Four, the server passes that payload to a facilitator and asks it to verify. Five, the facilitator confirms the signature and that the funds are good. Six, the server does the actual work, generating the response the client paid for. Seven, the server asks the facilitator to settle. Eight, the facilitator broadcasts and confirms the transfer on chain. Nine, the server returns the resource together with a settlement receipt header. The ordering in steps six and seven is the detail worth noticing: the work happens before settlement, so a seller carries a small amount of risk per call in exchange for not making the buyer wait on a block confirmation.
What is inside a 402 response?
The response body is the whole interface, and it is small enough to read in one sitting. At the top level sits x402Version, a number, and accepts, a non-empty array where each entry is one payment option the server will honor. A client that understands none of the offered options simply gives up; a client that understands several picks whichever it can settle most cheaply. Each entry names a scheme, which says how the payment is constructed. The scheme in production use is exact, meaning a fixed amount transferred to a fixed address. When the scheme is exact, the entry also carries network, maxAmountRequired, resource, payTo, asset and maxTimeoutSeconds. The table below is what each of those actually controls, because one of them is routinely misread as a spending limit and is not one.
What is an x402 facilitator?
A facilitator is the service that stands between an HTTP server and a blockchain so the server never has to speak to a chain directly. It does two jobs and only two: verify, meaning check that a signed payment payload is valid, well formed and backed by funds, and settle, meaning actually move the money on the seller's behalf across whichever networks and assets it supports. That separation is why a Python API can start charging per call without anyone on the team learning to manage wallets, gas or reorgs. Coinbase runs a facilitator through its Developer Platform, and the v2 architecture lets others plug in as first-class citizens rather than forks. Whether you use a hosted one or stand up your own is a real engineering decision with cost, latency and trust consequences, and we walk through it in what an x402 facilitator does and whether to run your own.
What changed in x402 v2?
Version 2 landed on June 24, 2026 and is the version to build against. The headline change is cosmetic but breaking: the protocol dropped the deprecated X- prefixed headers, so X-PAYMENT became PAYMENT-SIGNATURE and X-PAYMENT-RESPONSE became PAYMENT-RESPONSE. The official SDKs detect both and stay backward compatible with v1, which is generous, but anything of yours that inspects headers directly will not: log pipelines, WAF rules, API gateway policies and analytics that filter on the old names go quietly blind rather than failing loudly. Check those before you assume the migration was free. Underneath the rename, v2 is the more consequential release. Chains are now identified with CAIP identifiers instead of bespoke strings, the SDK became plugin-driven so developers register networks, assets and payment schemes rather than patching internals, payTo can be routed per request to different addresses or callback logic, and a Discovery extension lets facilitators index paid endpoints and their prices automatically so agents can find them.
Who controls x402 now?
x402 started at Coinbase and no longer belongs to it. The Linux Foundation announced its intent to host the protocol in April 2026, choosing the second of the month as a nod to the status code, and the x402 Foundation launched operationally on July 14, 2026 with 40 member organizations. The membership is the part worth reading closely, because it is not a crypto-only roster. Premier members include Visa, Mastercard, American Express, Fiserv, Adyen, Stripe, Google, AWS, Cloudflare, Shopify, Circle, Coinbase, Ripple, MoonPay, and the Solana, Stellar and Monad foundations. General and associate members add Fireblocks, Polygon Labs, NEAR, LayerZero, Quant Network, KakaoPay, zerohash and the Cardano Foundation among others. When the card networks and the largest acquirers join the governing body of a stablecoin-settled HTTP protocol, the reasonable read is that they expect machine-to-machine payments to be a separate lane from card checkout rather than a threat to it.
What is x402 actually good for?
The honest scope is narrower than the coverage suggests, and knowing the edges saves you a wasted quarter. x402 is strong where payments are small, frequent and machine-to-machine: paying per API call, per inference, per MCP tool invocation, per scraped page, per dataset query, or agent to agent for a subtask. At those sizes card rails are economically impossible, since a fixed authorization fee dwarfs a payment worth a fraction of a cent, and x402 settles for a fraction of that. It is also unusually good at first contact, because an agent can transact with a service it has no relationship with, no account on and no API key for. Where it does not fit is ordinary retail. Settlement is a stablecoin transfer on chain, so the merchant has to accept that asset, which almost no US storefront does. There is no chargeback, no dispute process and no card network arbitration, so a payment that buys nothing is simply gone. If your agent needs to buy from businesses that take cards, you want a scoped virtual card or a network agentic token instead, which we lay out in agentic payments and the rails agents pay over.
x402 compared to the checkout protocols
It is easy to lump x402 in with the Agentic Commerce Protocol, Google AP2 and UCP because they all arrived during the same eighteen months and all mention agents. They solve different problems. ACP and UCP standardize the handshake between an AI shopping surface and a merchant, so an agent can browse a catalog, build a cart and complete a checkout against an existing payment method. AP2 standardizes the mandate, a signed record of what a human authorized an agent to do. x402 skips shopping entirely: there is no cart, no catalog and no merchant of record, just a resource with a price. The practical consequence is that they compose rather than compete. An agent might use ACP to buy a physical product and x402 to pay for the data it used to decide what to buy, in the same task. The full three-way breakdown is in AP2 vs ACP vs x402.
x402 compared to MPP, the other HTTP 402 standard
Since March 2026 x402 has a direct rival using the same status code. The Machine Payments Protocol, co-authored by Stripe and Tempo and submitted to the IETF standards track, also answers an unpaid request with HTTP 402 and a challenge. Two differences decide which one fits. Payment methods: x402 is blockchain-only, so the payment is always a stablecoin transfer, while MPP treats the method as an extension point and ships production support for stablecoins, cards and Lightning. For a buyer whose treasury will not hold crypto, that is not a preference, it is the whole decision. Production primitives: idempotency, expiration and request-body binding sit in the MPP base specification, whereas around x402 you generally build them yourself. x402 keeps two real advantages: it is permissionless in a way a chain with a curated validator set is not, and it has been running in the open for longer. Neither standard defines a spending limit, which is the subject of the next section.
The gap x402 leaves you: nobody set the buyer a budget
Read the specification looking for a spending limit and you will find maxAmountRequired and think you have found one. You have not. That field is the seller declaring the most it will charge for this one call, and it protects the seller from a client that underpays, not you from an agent that overspends. Nothing in x402 knows how much your agent has already spent this hour, whether a counterparty is one you trust, or whether a person would have approved this if asked. The protocol is stateless by design and that is a reasonable design; budgets are a property of the payer, not of the payment. It does mean that if you point an agent at a wallet and let it pay 402s, the ceiling on your losses is the wallet balance, and a retry loop against a mispriced endpoint will find that ceiling faster than your alerting will. The control has to live above the rail: a hard per-agent budget, a per-counterparty cap, an approval threshold above which a human is asked, and a record that ties every settled payment back to the agent and the task that caused it. AWS built exactly this shape into Bedrock AgentCore Payments, where a payment session carries a maxSpendAmount and the limit check runs before the payload is signed, so a denied payment never touches the chain. We cover the ceiling question directly in can you set spending limits on x402, and Agentspay enforces those limits across x402 and card rails alike from one place.
The clearest illustration now ships from AWS. Amazon Bedrock AgentCore Payments reached general availability on 18 August 2026 as a managed x402 client, and it does set a ceiling, which is more than most implementations bother with. The ceiling is one optional amount per payment session, denominated only in USD, on a session that expires after at most 480 minutes, with no cumulative total anywhere in its API. We measured the whole surface on our AWS AgentCore spend controls page.