What Is x402?

Definition

x402 gives HTTP 402 a concrete payment shape. The current HTTP spec reserves status code 402 without defining a universal payment convention. x402 fills that gap by standardizing the objects and headers that let a server advertise a price and let a client resubmit the request with payment authorization.

The protocol is useful when the thing being sold is already an HTTP resource: an API call, a file, a page, a model inference, a data lookup, or a tool response. That is why x402 matters for agentic commerce. Agents can parse machine-readable requirements and decide whether to pay without creating a human account for every service they touch.

x402 is not a wallet, blockchain, processor, or paywall UI by itself. It is a transport-level pattern plus reference SDKs. Implementations still choose networks, assets, signers, facilitators, risk policies, refund handling, and user experience.

Where it fits

The cleanest x402 fit is a resource with clear marginal value and low transaction friction: a data endpoint, AI tool, one-off premium document, search result, render, crawl, inference, or metered compute call. Traditional subscriptions still make sense where the buyer needs ongoing access, negotiated terms, bundled support, or a procurement trail.

The current ecosystem is strongest around stablecoin payments and onchain settlement, but the protocol direction is broader. The public docs and Cloudflare proposal both describe facilitator and scheme flexibility, including deferred and batch patterns where immediate onchain settlement is not the right economic model.

• Use x402 when the buyer can decide per request and the resource can be priced before or during the request.
• Avoid x402 as the only control plane for regulated, revocable, high-dispute, or account-heavy products.
• Treat it as an interoperability layer, not as a substitute for product pricing, fraud policy, accounting, or support.

The four roles

A client wants the resource. A resource server owns the HTTP endpoint. A facilitator can verify and settle payments across networks. A network or payment rail moves value according to the selected scheme. Keeping those roles separate prevents a common mistake: assuming the server must become chain infrastructure.

The seller middleware examples show the intended developer experience. You register schemes and route requirements, wrap the protected endpoint, and let the x402 server layer handle 402 responses, verification calls, settlement calls, and response headers.

• Client: parses PAYMENT-REQUIRED and signs a payment payload.
• Resource server: declares requirements, verifies payloads, settles payments, and serves resources.
• Facilitator: abstracts chain-specific verification and settlement behavior.
• Scheme/network: determines exact amount, maximum amount, batch settlement, token, and chain semantics.