x402 is an open standard for internet-native payments. It uses the long-reserved HTTP 402 "Payment Required" status code to carry a payment challenge.
In a common x402 v2 HTTP flow, a client asks for a resource, the server answers 402 with payment terms, the client signs a payment and retries, and the server returns the resource. The standard is network- and currency-agnostic, and actual networks, assets and schemes depend on the implementation.
HTTP has included status code 402, "Payment Required", since early versions of the protocol, but it was reserved for future use (RFC 9110 keeps that reservation) and the web grew up without a standard way to charge per request. APIs instead settled on accounts, API keys, subscriptions and invoices. Accounts, subscriptions and invoicing can add setup overhead when software needs a single paid request.
x402's answer is to make payment a property of the HTTP request itself. A payment-capable client can use this flow without a seller account or API key when the service permits it; sellers and payment providers may impose their own access requirements.
The x402 specification describes an exchange between a client, a resource server and an optional facilitator. In the common x402 v2 HTTP flow:
A facilitator is a service that can handle payment verification and settlement for a supported scheme and network, reducing payment-infrastructure work for the resource server. For production mainnet routes the README advises choosing a facilitator model explicitly - a production facilitator provider that supports your target network, running your own, or self-facilitating inside the resource server - rather than assuming the public x402.org facilitator is the default production path. The standard's stated design goals include keeping this role trust-minimizing: a scheme must not let the facilitator or the server move funds other than as the client intended.
x402 is deliberately narrow. It standardizes how a price is quoted and paid inside HTTP. It does not standardize what a resource is worth, whether a seller is honest, or whether the data is good. Those judgments stay with the buyer, exactly as before. Payment authorization is not identity verification or a guarantee about the seller. A wallet or payment flow should not be assumed anonymous; service and provider identity requirements vary.
The specification defines payment schemes (the repository lists exact, upto and batch-settlement) and is network-, token- and currency-agnostic by design, with reference SDKs published for TypeScript, Python and Go.
x402 started at Coinbase and now lives under the x402 Foundation, an open project under the Linux Foundation; the specification repository moved from coinbase/x402 to x402-foundation/x402. The x402.org site lists ecosystem members including Alchemy, AWS and Cloudflare. "Open standard" here means the spec is public, contributions are open, and no single vendor is required to use it.
Dutiful uses x402 for paid Company Reports. A free coverage request returns candidate entities; after selection, the API returns payment requirements and a pay_url. The client authorizes USDC on Base and posts the signed payload to that pay_url, then retrieves the report through the order status endpoint. create_order does not pay by itself. The mechanics are documented in Dutiful's developer documentation. Other x402 services are listed in community directories such as x402scan.com.
Reference implementation README