How does x402 work? HTTP 402 payments explained

x402 gives the long-reserved HTTP 402 Payment Required status code a practical role in API transactions. Instead of sending users or software to a checkout flow, a server can return payment terms directly in HTTP, letting clients and AI agents pay programmatically and continue the request in a standard request-response pattern.

What x402 changes

x402 treats payment as part of the normal HTTP exchange. When a protected endpoint is called, the server responds with 402 and includes the information needed to continue. That keeps payment native to the transport layer developers already use rather than forcing a separate billing workflow.

The model is aimed at monetizing APIs, content, and machine-to-machine services without accounts, sessions, or manual invoicing. For technical teams, the main appeal is a stateless, machine-readable payment checkpoint that fits both software clients and AI agents.

How the payment flow works

The flow is straightforward. A client first makes a normal request to a paid endpoint. The server replies with 402 Payment Required and describes the accepted payment options. The client selects one, signs a payment payload with its wallet, and retries the same request with proof attached in a payment header.

The server then verifies the payload itself or passes that task to a facilitator. If the payment is valid, the server completes the requested work, settles payment directly or through the facilitator, and returns the resource. A success response can also include settlement details.

What the server must specify

For the process to work reliably, the 402 response has to tell the client exactly what is acceptable. That can include the payment scheme, network, amount, asset, payee, and resource metadata. A server can also advertise multiple acceptable payment options on the same endpoint.

The protocol supports standardized network identifiers and can express prices in human-friendly terms as well as precise atomic amounts. That makes micropayments easier to present while still giving clients exact settlement values for signing and verification.

Signing, verification, and facilitators

After receiving payment requirements, the client builds and signs a payload for the selected option and sends it back in the retried request. In practice, the wallet is both the payment tool and a form of buyer or agent identity. The underlying chain mechanics can differ, but the core pattern remains sign offchain, submit proof, then validate it.

A facilitator is optional but presented in the documentation as the recommended path for many sellers. It can verify that the signed payload matches the server’s requirements and may also submit settlement onchain. The hosted Coinbase facilitator is described as non-custodial, and it may sponsor gas depending on the deployment.

Support, security, and where Tilde Pay fits

It is important to separate the open x402 protocol from any particular service built around it. The reference tooling supports EVM-compatible and Solana-based token flows, while Coinbase’s hosted facilitator publishes its own supported network list and scheme coverage. A network may be supported in principle without every scheme being available in every deployment.