The status code that waited three decades
HTTP 402 Payment Required was reserved in the early HTTP specifications and left undefined because no viable digital payment mechanism existed at the time. x402 finally gives the status concrete semantics: instead of an error page, an unpaid request receives a machine-readable quote describing exactly what payment would unlock the resource.
The exact scheme on Base
A payment requirement names a scheme, a network, an asset, an amount, a recipient, and a validity window. In the common exact scheme on Base mainnet (eip155:8453), the asset is USDC and payment moves through EIP-3009 transferWithAuthorization: the buyer signs an off-chain authorization, and the payee or a facilitator submits it on-chain. The buyer therefore never needs ETH for gas, and the signed payload is valid only for the quoted amount, recipient, and time window.
The full request flow, step by step
First, the client sends an ordinary request, such as GET /v1/fetch. Second, the server answers 402 with a PAYMENT-REQUIRED header carrying base64-encoded JSON terms. Third, the client decodes the terms, selects an accepted payment option, and signs an EIP-3009 authorization with its wallet. Fourth, the client retries the identical request with a PAYMENT-SIGNATURE header. Fifth, the server verifies the signature and, on success, returns the resource together with a PAYMENT-RESPONSE header containing the settlement receipt. In x402 v2 the whole exchange is header-based, so any HTTP client can participate.
The facilitator: verify and settle
A server does not need to run its own node or wallet infrastructure. A facilitator exposes two operations: verify, which checks that the signature matches the quoted terms and the buyer holds sufficient funds, and settle, which submits the authorization on-chain. Santos settles only after producing a successful response (a status below 400): if the underlying request fails, the payment is never settled and no USDC moves.
Why this model suits agents
There are no accounts, no API keys, no subscriptions, and no invoices. An agent pays 0.002 USDC for one fetch instead of committing to a monthly plan it will never exhaust, and budgets become exact because spend can be capped per call. Identity is a wallet address, access control is a signature, and settle-on-success removes the refund negotiation that makes conventional prepaid credits awkward for autonomous software.
Discovery through Bazaar
A payment protocol only helps if agents can find services that speak it. Bazaar, the discovery layer of the x402 ecosystem, indexes payable endpoints so a client can enumerate available services, their prices, and their networks without prior bilateral knowledge. The eleven Santos tools are published there alongside the capability manifest, OpenAPI document, and llms.txt, so an agent can go from discovery to paid invocation without human setup.
Try it in five minutes
Run curl against https://api.santosautomation.com/v1/fetch?url=https%3A%2F%2Fexample.com and read the 402 response: the PAYMENT-REQUIRED header quotes 0.002 USDC on eip155:8453 with a recipient and expiry. Decode the header, sign the quoted terms with any x402 client library (the reference SDK wraps fetch and axios to handle challenge, signing, and retry automatically), and repeat the request. The response returns the fetched content plus a PAYMENT-RESPONSE receipt. The identical flow works for every Santos capability, from Feed Parser at 0.003 USDC to Batch Audit at 0.50 USDC flat.