Inside x402: Enabling Payments with HTTP 402

The internet is finally getting a native payment layer. HTTP 402—originally reserved as "Payment Required"—is being revived by the x402 specification to make the web natively payment-aware.

Last updated: September 13, 2026. Verified against the x402 specification repository at specs/x402-specification-v1.md, specs/x402-specification-v2.md and specs/schemes/.

See how Openfort enables agentic commerce — programmable wallets that let agents pay autonomously. For how x402 fits alongside the other agent payment protocols, see the agentic payments landscape.

What is x402 and How Does It Work?

x402 is an open specification that standardizes how web APIs handle payments directly within the HTTP protocol stack. Instead of using third-party checkout pages or specialized SDKs, a server can respond with a 402 status code to indicate that access to a resource requires payment in a specific asset (like USDC). The client then signs an authorization using their digital wallet, which a facilitator settles on-chain. This creates a specialized, machine-readable payment flow that is ideal for AI agents, automated APIs, and micro-transactions, allowing "payment negotiation" to happen as smoothly as authentication.

x402 bridges the worlds of web APIs and digital money. It proposes that instead of manually implementing payment flows with separate SDKs or redirecting users to off-site checkout pages, payment negotiation and fulfillment could happen directly at the HTTP layer — just like authentication or caching.

x402 aims to make “payment” a first-class citizen of the internet protocol stack.

How x402 works

x402 standardizes how a client, a server, and optionally a facilitator interact when a resource requires payment.

The Three Participants

• Server: Owns premium data or content and defines the payment requirements (e.g. amount, asset, chain).
• Client: Requests access to the resource, equipped with a wallet capable of signing.
• Facilitator: A piece of middleware or infrastructure that abstracts verification, settlement, and on‑chain interactions.

Payment Flow

1. The Client requests a protected endpoint, e.g. /premiumdata.
2. The Server replies with a 402 Payment Required response, detailing the payment requirements (such as 100 USDC on Base).
3. The Client signs a payment authorization off‑chain — a signed message, not a broadcast transaction. The client never touches the chain and never pays gas, which is the property the whole design rests on.
4. The Server or Facilitator verifies the signature and terms, checking that the payment satisfies the stated conditions.
5. The Facilitator performs the on‑chain settlement, handling the gas, nonce, and key management behind the scenes.
6. Once the server receives confirmation, it responds with a 200 OK — delivering the requested premium content or data.

What the client actually signs in step 3 depends on the scheme and the chain, and this is worth being precise about because it is often described wrongly. For the exact scheme on EVM chains, the recommended method is ERC‑3009's transferWithAuthorization, which tokens such as USDC implement natively; the specification's fallback for ERC‑20 tokens without ERC‑3009 is Permit2. Non‑EVM chains use their own primitives entirely — the XRP Ledger binding, for example, has the payer sign a Payment transaction. ERC‑3009 is one scheme's implementation detail on one family of chains, not the mechanism of x402.

The facilitator works like a payment processor such as Stripe, except decentralized, network‑agnostic, and compatible with both crypto and (eventually) fiat rails.

Why x402 matters

Today, web payments are trapped inside siloed SDKs, checkout pages, and API keys owned by proprietary providers. For machine‑to‑machine use cases — such as AI agents, APIs, or decentralized applications — that model doesn’t scale.

x402 shifts payments from an application concern to a protocol concern. By defining how payments can be negotiated, verified, and fulfilled directly at the HTTP (or transport‑agnostic) layer, x402 unlocks:

• Native web interoperability. Clients and servers speak a shared payment language.
• Protocol‑level programmability. Any API or service can require payment as part of the request lifecycle.
• Multi‑network support. Crypto, fiat, or hybrid rails coexist through standardized schemas.

This makes pay‑per‑use, micro‑transactions, or pay‑gated APIs possible without relying on centralized intermediaries.

x402 v1: The foundation

Version 1 of the specification focused on proving that machine‑readable payment negotiation could work. The key ideas included:

• HTTP Status 402 as the entry point: Servers responded with a structured PaymentRequirements object when access required payment.
• Facilitators as neutral executors: Responsible for verifying client signatures, ensuring validity, and (optionally) executing the transaction.
• Transport independence: While rooted in HTTP, the spec was designed to work across WebSocket, WebTransport, or other message-based transports.
• Crypto‑first network identifiers: Networks were named as bare strings, such as base-sepolia.
• Wire format: The client sent its signed payload in an X-PAYMENT header, and the server returned the settlement result in X-PAYMENT-RESPONSE.

v1 laid the groundwork for interoperable pay‑to‑access flows, but as adoption grew, new requirements emerged — non‑blockchain rails, metered pricing, and a way to add features without reopening the core spec.

What changed in x402 v2

Version 2 of the specification shipped on December 9, 2025. It is not an incremental revision, and the single most important thing to know about it is the part that is easiest to get wrong.

v2 is not wire‑compatible with v1

Every header on the wire was renamed, and the v2 specification contains no backward‑compatibility provision — no negotiation mechanism, no transition period, no dual‑version support.

A v1 client and a v2 server will not interoperate. If you are upgrading, check which version your facilitator, your middleware and your client library each implement, and move them together.

What v2 added

• CAIP‑2 network identifiers. Networks are now namespaced (eip155:8453, solana:…), which is what makes the next item possible.

• Non‑blockchain networks. The specification states that non‑blockchain networks are encouraged to follow the CAIP‑2 format, giving ach:us and sepa:eu as examples. This is already more than theoretical: the batch-settlement scheme has a shipped binding for the network identifier cloudflare:402, where Cloudflare acts as merchant of record, requests are authenticated with HTTP Message Signatures (RFC 9421), and settlement is billed later rather than on‑chain per request.

• Four payment schemes, not one. Alongside exact (a fixed amount known in advance), v2 specifies upto — authorize a maximum, charge the real amount at settlement, for metered pricing like LLM tokens or bandwidth; batch-settlement, where a signed commitment grants access immediately and value moves later through the network binding, for the case where per‑request gas would cost more than the payment; and auth-capture, which gives a payment a lifecycle — hold it, capture less than the ceiling, cancel it, or return it after the fact. auth-capture matters because exact moves a fixed amount once and offers no way to give it back, so refunds and buyer protection had no home in the protocol before it.

• A restructured core. PaymentRequired and PaymentPayload were reorganised, and information about the resource itself was split out into a separate ResourceInfo object.

• An extensions mechanism. Both objects now carry an extensions field, so optional features ship as named extensions instead of accreting onto the core schema. Several features often described as core v2 in fact live here: sign-in-with-x (CAIP‑122 wallet‑ownership proof, using eip191 on EVM or ed25519 on Solana), offer-and-receipt (servers issue EIP‑712 or JWS signed receipts for completed payments), and payment-identifier (an id field used as an idempotency key, so a resubmitted payment returns the cached response instead of charging twice).

• Replay protection in the core spec. This is handled by nonces, not by receipts: each authorization carries a 32‑byte random nonce, contracts reject nonce reuse on‑chain, and authorizations carry explicit validity windows.

What v2 deliberately left out

The specification names its own exclusions, and two of them matter if you are building agent payments: session handling mechanisms and client‑side budget management are both listed as out of scope.

That is a reasonable boundary for a wire protocol, but it means x402 does not answer the question most teams actually have about an autonomous agent — how much is it allowed to spend, and on what. The protocol moves a payment once it has been authorized. Deciding whether to authorize it belongs to whatever holds the keys, which is why programmable spending controls sit in the wallet layer underneath x402 rather than inside it.

The bigger picture

If successful, x402 could do for payments what HTTP did for documents — a universal layer that anyone can build on. Imagine APIs, AI agents, or cloud endpoints that can natively charge for usage, without embedding third‑party processors.

The v2 overhaul reflects the maturation of this idea: from a crypto‑centric prototype to a transport‑agnostic framework for programmable value exchange, with an extension mechanism so it can keep growing without breaking again.

The governance moved with it, in two stages. On April 2, 2026, announced at the MCP Dev Summit North America in New York, the Linux Foundation said it was launching the x402 Foundation and welcoming the contribution of the x402 protocol from Coinbase; around 22 organizations expressed initial support, and the Linux Foundation describes the governing body as initially developed by Coinbase, Cloudflare and Stripe. On July 14, 2026, Coinbase's transfer formally completed, placing the protocol under vendor‑neutral control for the first time, with 40 member organizations and the project formalized as "x402, a Series of LF Projects, LLC."

The canonical repository is x402-foundation/x402, licensed Apache‑2.0, having moved from coinbase/x402; the technical charter in that repository is dated March 31, 2026. Describing x402 as "Coinbase's protocol" was accurate at the start and is no longer — Coinbase created it, but does not own it.

The direction is clear: x402 aims to make "Payment Required" a message every connected machine can understand. For how it sits alongside MPP, ACP and AP2, see our agentic payments landscape overview.