x402 is an open payments protocol that uses HTTP’s 402 Payment Required status code to let a client pay for a resource in the course of requesting it, with no account, no signup and no prepaid credits. A resource server answers with a PaymentRequired object listing what it accepts, the client returns a signed payment payload, and a third role — the facilitator — verifies and settles it, usually in stablecoins on-chain. It deliberately separates transport (HTTP, MCP, A2A) from payment scheme (exact, upto, batch settlement) from network. Released by Coinbase on 6 May 2025 and contributed to the Linux Foundation, where the x402 Foundation became operational on 14 July 2026.
x402
x402 is the other answer to the same question the Machine Payments Protocol is answering: what should happen when a machine asks for something that costs money. Coinbase released it on 6 May 2025, authored by Erik Reppel, Nemil Dalal and Dan Kim, and contributed it to the Linux Foundation — where, unlike almost everything else in this corner of the catalog, it now has a real institutional home. The technical charter is dated 31 March 2026, the x402 Foundation went operational on 14 July 2026 with roughly forty member organizations, and the code and specifications live in one Apache-2.0 repository under x402-foundation/x402 with reference SDKs in TypeScript, Python, Go and Java.
- The paywall is in the headers, and they changed - In v2 the server returns
402with a base64-encodedPaymentRequiredobject in aPAYMENT-REQUIREDresponse header; the client returns a signed payload inPAYMENT-SIGNATUREand gets settlement confirmation back inPAYMENT-RESPONSE. v1 usedX-PAYMENTandX-PAYMENT-RESPONSE. Both transport specifications are still maintained in the repository and every message carries anx402Versioninteger, so anything built during 2025 is on the older wire format and knows it. - Three roles, and the third one is new - Resource server, client, and facilitator — a service that verifies payments and settles them on-chain so neither end has to hold gas, run RPC or understand the network. It is the most consequential design decision here: adopting x402 means trusting an intermediary that did not exist in your architecture yesterday, and the v2 work makes multi-facilitator support a feature rather than an accident.
- Transport, scheme and network are separated on purpose - Transports are specified for HTTP,
MCP and A2A. Schemes describe how money
moves —
exactfor a stated amount,uptofor a ceiling, plus batch settlement — and each scheme is then implemented per network.exactalone has documents for EVM, Solana, Stellar, Sui, Aptos, Hedera, Algorand and Keeta. Networks are named with CAIP-2 identifiers rather than invented strings. - Discovery falls out of the paywall - The
bazaarextension puts the endpoint’s own specification — HTTP method or MCP tool name, input parameters, output format — inside the 402 response, with a JSON Schema describing it, so facilitators can catalog and index paid endpoints. A payment-required response becomes a discovery record, which is a different route to the problem ARD is solving from the publisher’s side. - Governance that actually names people - The technical steering committee is three organizations and three representatives: Erik Reppel of Coinbase, Rohin Lohe of Cloudflare and Steve Kaliski of Stripe. Premier membership runs to seventeen organizations including Visa, Mastercard, American Express, Adyen, Fiserv, Google, AWS, Shopify, Circle and Ripple, with general and associate tiers below it. Against MPP’s two-company CODEOWNERS file, this is a different category of neutrality — and worth reading as such rather than as a technical judgment.
- Stripe is on both sides, in the same person - Steve Kaliski sits on the x402 TSC and is a co-author of the MPP IETF draft; Stripe is a premier member of the x402 Foundation and co-published the competing scheme with Tempo. That is not hedging to be embarrassed about, it is what a payments company does when the standard is undecided — but any provider betting on “the 402 standard” should know that the companies closest to it have not picked one either.
- No published schema artifact for the core types -
PaymentRequired,PaymentPayloadandSettlementResponseare specified in Markdown tables. Zod definitions ship in the TypeScript SDK and pydantic models in the Python one, and the extensions carry inline JSON Schema for their own payloads, but there is no fetchable metaschema for the protocol itself — so validation today means trusting a reference implementation rather than a document. - The adoption number is self-reported - The V2 launch post claims over 100 million payments in the protocol’s first six months. There is no third-party audit behind that figure, and on-chain volume counts differently than any API metric you already track. Treat it as a vendor claim, which is how it is written.
The two protocols have arrived at nearly the same place from opposite directions. MPP models payment as an HTTP authentication scheme and went to the IETF as an individual draft; x402 models it as a payload carried by whatever transport you are already on and went to the Linux Foundation with the card networks in the room. Neither is a settled standard, and the sensible read for an API provider is not to pick a winner yet. It is that the pricing, the rate limits and the scopes that currently live on a marketing page and in a PDF are about to be things a machine has to read at request time — and the work of making those machine-readable is the same work regardless of which of these two ends up carrying the money.