x402

The project describes x402 as an open, neutral standard for internet-native payments. It states the problem in its own words: filling out a form is a human behaviour that does not match the programmatic nature of the internet. The specification is public and its source of record is the repository published by the x402 Foundation. The Linux Foundation announced that body's operational launch, describing it as an open-governance body formed to steward the protocol under that foundation's neutral governance.

The exchange is four steps. A request arrives unpaid. The endpoint answers HTTP 402 with a payment challenge — the terms it will accept, as data a client can read without a person. The client picks one of those terms, signs an authorization for it, and retries with the authorization attached. The endpoint has that authorization checked and settled by a facilitator, then serves what was asked for.

Where the terms travel is decided by the transport. The current HTTP transport carries them in headers: the quote in PAYMENT-REQUIRED, the signed authorization in PAYMENT-SIGNATURE on the retry, and the settlement result in PAYMENT-RESPONSE. The project's own note on that version describes the change as moving all payment data to headers, freeing the response body for other use. It states that the reference SDKs — the project's own client libraries — remain backward-compatible with the earlier version. That earlier transport put the quote in the response body as JSON, and live endpoints still answer that way.

The specification names the parts an implementer meets. A scheme is how a payment is formed, validated and settled, and the repository carries a document for each one it defines: exact, upto, auth-capture and batch-settlement. Each option in the accepts array pairs a scheme with a network, an asset, an amount and the payTo address that receives the transfer. Extensions add optional behaviour without anyone forking the specification: a server advertises the ones it supports in the challenge, and a client echoes them back in its payload.

Two things it does not do are worth stating, because both are routinely assumed. It does not require a particular blockchain — the project describes the standard as blockchain-agnostic, supporting EVM-compatible chains and Solana among others, and extensible to traditional payment methods. And it establishes nothing by itself about the endpoint being paid. The protocol carries an offer and a payment. Whether an endpoint quotes today what it quoted last week, and whether the receiving address has changed, are questions about a series of observations rather than about the protocol.