How does x402 work? HTTP 402 payments explained

x402 uses the HTTP 402 Payment Required status code as a machine-readable payment checkpoint inside a normal request-response flow. A client requests a paid API or resource, the server returns payment requirements, the client signs a payment payload and retries, and the server verifies and settles payment before returning the resource.

Rather than adding a checkout page to an API, x402 expresses payment requirements directly in HTTP so software clients, including AI agents, can pay programmatically. The protocol is designed to monetize APIs and content without accounts, sessions, or traditional billing flows.

What x402 is and why HTTP 402 matters

HTTP 402 has long existed as a reserved status code for payment, but it saw little production use. x402 gives it a concrete role: when an endpoint requires payment, the server responds with 402 and includes the payment instructions a client needs to continue.

That keeps payment native to the transport developers already use. Instead of redirecting to a form or building a custom authentication handshake, the server can declare payment in standard HTTP terms. The docs describe this approach as stateless and HTTP-native, which fits API-to-API and agent-to-agent use cases.

The x402 payment flow

The basic flow is simple. A client sends a normal HTTP request to a protected endpoint. The resource server responds with 402 Payment Required and includes requirements in the PAYMENT-REQUIRED header. The client selects a supported option, signs a payment payload with its wallet, and retries with a PAYMENT-SIGNATURE header.

The resource server then verifies the payment payload locally or through a facilitator. If valid, it performs the requested work, settles payment onchain directly or through that facilitator, and returns the resource. A successful response can also include a PAYMENT-RESPONSE header with settlement details.

What the payment requirements include

For x402 to work, the 402 response must tell the client exactly what to pay and how. The PAYMENT-REQUIRED header can include the scheme, network, amount or price, payee address, and metadata about the resource. The protocol also supports an accepts list, so a server can advertise more than one valid payment option on the same endpoint.

Network identifiers in v2 use CAIP-2 format, which standardizes chain naming across environments. The docs also show both human-readable prices, such as $0.001, and atomic-unit amounts. That lets sellers express micropayments clearly while still giving clients the exact values needed for settlement.

How clients sign and submit payment

After receiving the 402 response, the client chooses one advertised payment requirement and builds a payload for the specified scheme and network. It signs that payload and attaches it to the retried request in the PAYMENT-SIGNATURE header. In practice, the wallet acts as both the payment mechanism and a unique buyer or agent identity.

On EVM networks, the reference tooling supports EIP-3009, or Transfer With Authorization, for tokens such as USDC and EURC that support it, and Permit2 for broader ERC-20 support. On Solana, the reference SDKs support SPL Token Program tokens and Token2022 tokens. The chain mechanics differ, but the protocol idea stays the same: sign offchain, submit proof, then validate against the original requirements.

What facilitators do

A facilitator is optional, but the documentation presents it as the recommended model for most sellers. It verifies that the signed payment payload matches the declared requirements and can also settle the payment onchain on behalf of the resource server. That removes much of the chain-specific verification and settlement work from the seller.

The hosted facilitator documentation also says the facilitator does not hold funds or act as a custodian. It validates and submits transactions based on payloads already signed by the client. Coinbase’s hosted service may also sponsor gas for settlement, which helps reduce the need for buyers and sellers to manage native gas tokens in every supported network.

Supported networks, schemes, and standards

It is important to separate the open protocol from any specific facilitator deployment. At the protocol and reference SDK level, EVM support can be configured for EVM-compatible chains and ERC-20 tokens through EIP-3009 or Permit2. Solana support covers SPL tokens and Token2022 through the reference SVM package.

For the Coinbase Developer Platform facilitator, the published network list includes Base, Base Sepolia, Polygon, Arbitrum, World, World Sepolia, Solana, and Solana Devnet. Scheme support varies by network. The docs distinguish schemes, such as exact or upto, from networks, which matters because a chain may be supported in principle without supporting every scheme in a given deployment.

Security and operational considerations

The main security goal is to keep payment execution tied to explicit client intent. Implementations should verify that a payment payload matches the declared amount, scheme, asset, network, and payee from the 402 response. Verification cannot be just a syntax check; it must confirm that the payload is valid for settlement and still aligned with the seller’s stated requirements.

Implementations also need replay protection and clear scope control so signatures remain bound to the correct resource, amount, and settlement context. Coinbase’s hosted facilitator adds compliance screening, including KYT checks that may decline payments involving sanctioned or high-risk addresses. That screening is a facilitator feature, not a property of the open x402 standard itself.

Use cases and where Tilde Pay fits

The clearest use case is pay-per-request API access for services such as weather, search, model inference, or blockchain data. Other patterns include content paywalls, microservices that bill each other per invocation, and agentic commerce, where an AI agent discovers a paid endpoint, receives a 402 response, signs payment, retries the call, and continues without account creation or manual invoicing.

Tilde Pay is separate from the x402 protocol itself. Its public homepage describes infrastructure for AI agents, including funded wallets, bank deposit rails, and x402 or MPP payment tools, along with spend controls. Based on that public material, the narrow claim is that Tilde Pay positions itself as agent payment infrastructure that may use x402, not as the canonical spec, facilitator, or seller-side gateway.