402 Payment Required status code. It defines how a server communicates that
payment is required to access a resource, and how a client can provide proof of
payment. x402 is not a payment system itself. It is a negotiation protocol,
agnostic to how payments are constructed, verified, or settled.
Circle operates two x402 facilitators.
Facilitator Service settles USDC onchain on every
payment through a Circle relayer. Gateway Nanopayments
batches signed authorizations into aggregated settlement to make sub-cent
payments economically viable. Both plug into the same x402 flow.
For the full protocol spec, see x402.org and the
x402 documentation. The reference implementation lives
in the x402 GitHub repository.
The problem with internet payments
Traditional payment systems were not designed for programmatic, high-frequency transactions. Credit cards carry high fixed fees, require account creation, and involve slow settlement. Standard onchain payments require gas for every transaction, making sub-cent payments uneconomical. Neither approach works well for AI agents, per-request billing, or machine-to-machine commerce. x402 addresses this by making payment negotiation a native part of HTTP. A server declares that payment is required, a client provides a payment payload, and the exchange happens in a single request-response cycle. The actual payment method is flexible. Any scheme that can produce a verifiable payment payload can work with x402.How x402 works
The x402 protocol uses three HTTP headers to negotiate payment between a client and a server:
The typical flow is:
- The client requests a paid resource.
- The server responds with
402 Payment Required, including payment details such as the accepted payment schemes, price, network, and destination address. - The client selects a payment option, constructs and signs a payment payload,
and retries the request with the
PAYMENT-SIGNATUREheader. - The server verifies the payment (directly or through a facilitator) and
returns the resource along with a confirmation in the
PAYMENT-RESPONSEheader.
Core concepts
Buyers and sellers
- Buyer (client): The entity requesting a paid resource. This can be a human-operated application, an AI agent, or any programmatic HTTP client. Buyers construct payment payloads using whatever payment method the server accepts.
- Seller (server): The resource provider that requires payment. Sellers
declare their accepted payment methods in the
402response, verify incoming payment payloads, and serve the resource when payment is valid. Any HTTP-accessible API or service can act as a seller.
Facilitators
A facilitator is an optional service that handles payment verification and settlement on behalf of sellers. By using a facilitator, sellers avoid needing to verify payment payloads or interact with blockchain infrastructure themselves. Different facilitators can support different payment methods. A seller connects to a facilitator and automatically gains access to the payment methods that facilitator supports. Circle operates two: Facilitator Service and Gateway Nanopayments.Payment schemes
x402 supports multiple payment schemes. A payment scheme defines how payment payloads are constructed, signed, and verified. The402 response from a server
lists the schemes it accepts, and the client picks one it can fulfill.
Both Circle facilitators use the exact scheme with EIP-3009
TransferWithAuthorization signatures. They sign against different EIP-712
domains because they use different settlement models.
How Facilitator Service fits in
Facilitator Service settles each x402 payment onchain through a Circle relayer:- Buyers sign an EIP-3009
TransferWithAuthorizationagainst the USDC contract on Arc, Base, or Polygon PoS. - The seller passes the signed authorization to Facilitator Service.
- Facilitator Service verifies the signature, screens both parties, and submits the USDC transfer onchain. Circle pays the settlement gas.
How Gateway Nanopayments fits in
Gateway Nanopayments uses Circle Gateway’s batched settlement infrastructure to make sub-cent payments economically viable:- Buyers fund their payments from a Gateway Wallet balance (deposited once onchain).
- When a server requests payment through a
402response, the buyer signs an offchain EIP-3009 authorization against theGatewayWalletBatcheddomain (zero gas) and includes it in thePAYMENT-SIGNATUREheader. - The server or its facilitator submits the authorization to Gateway for verification and settlement.
- Gateway collects authorizations and settles net positions in bulk onchain, paying gas once per batch instead of once per payment.
402 negotiation flow. The difference is that
the underlying payment is gasless and settled through batching, which is what
makes sub-cent payments economically viable.