What is x402?
Last Updated: August 29, 2026
x402 is an HTTP payment standard. A server returns the standard HTTP 402 Payment Required status with a structured payment requirements payload. The caller signs a USDC payment locally and retries with a payment header. The server verifies the signature, fulfills the request, and settles on-chain.
The full request flow
- Client makes a normal HTTP request:
POST /api/v1/chat/completions - Server replies
402 Payment Requiredwith payment requirements (amount, asset, recipient, network). - Client signs an EIP-3009
TransferWithAuthorizationpayload locally. The private key never leaves the device. - Client retries the same request with
x-paymentheader containing the signed authorization. - Server verifies the signature, fulfills the request, and settles the USDC transfer on-chain. Settlement happens in the same request — non-custodial and instant.
Why does this exist?
AI agents can hold USDC. AI agents cannot hold a credit card. Subscriptions and prepaid credits assume a human on the other end of the billing relationship — they break for autonomous agents that need to pay for one API call right now, with no account or signup.
x402 reuses HTTP's existing 402 status code (it has been reserved for “future use” since 1997) and pairs it with stablecoin settlement. Per-request, no account, no minimum spend.
x402 on BlockRun
Every endpoint on BlockRun is x402-native. Send a request without a payment header, get a 402 response with the price for that exact call. Sign with your wallet, retry, get the response. No API key, no signup, no subscription.
We support x402 on Base mainnet and Solana mainnet. Settlement uses the Coinbase CDP facilitator. The full protocol spec lives at x402.org.
What a 402 response actually looks like
This is the whole protocol in one payload. Send any paid request with no payment header and this comes back — the price is computed for that exact call, not read off a rate card, which is what lets a per-request price exist at all.
HTTP/1.1 402 Payment Required
{
"x402Version": 2,
"accepts": [
{
"scheme": "exact",
"network": "eip155:8453",
"amount": "<price of this call, in USDC base units>",
"asset": "<USDC contract on that network>",
"payTo": "<recipient address>",
"maxTimeoutSeconds": 300
}
],
"error": "Payment Required"
}A caller reads accepts, picks an entry it can satisfy, signs a transfer for that amount to that payTo, and retries. The signature authorises one transfer of one amount to one recipient: the server can settle it or nothing, and it cannot draw on it twice.
x402 vs the alternatives: cards, Lightning, and prepaid credits
| Approach | Who it assumes is buying | What it needs first |
|---|---|---|
| x402 | Software with a stablecoin balance | A funded wallet |
| Card rails / agent checkout | A human cardholder behind the agent | A card, a merchant account, a chargeback process |
| L402 / Lightning | A bitcoin holder with a channel | A node or custodial wallet, an open channel |
| Prepaid API credits | An account holder who tops up ahead of time | Signup, a payment method, a balance |
None of these is wrong for its buyer. The distinction that matters is who is on the other end: every row but the first assumes a human completed something in advance — a signup, a card, a channel. x402 is the one that works when the buyer is a program that woke up, needed one call, and has to settle it itself.
Related
x402 questions: what it is, how payment works, and what it replaces
- What is x402 in one sentence?
- An HTTP payment standard: the server answers a request it will not serve for free with the standard 402 Payment Required status and a machine-readable price, the caller signs a stablecoin transfer for exactly that amount and retries, and the server verifies the signature, serves the response and settles on-chain.
- How does an x402 payment actually work, step by step?
- Send the request with no payment header and read the 402 that comes back — it carries the amount, the asset, the recipient and the network. Sign a transfer authorization locally; the private key never leaves the machine. Retry the same request with that signature in a payment header. The server verifies it before doing any work, and settles after.
- Do I need an account or an API key to pay with x402?
- No. The wallet is the account. There is nothing to sign up for, no key to issue or rotate, and no minimum balance beyond the cost of the call you are making — which is why it works for an autonomous agent that has to buy one API call right now and has no way to complete a signup form.
- Is x402 a blockchain, a token, or a company?
- None of the three. It is a convention for using an HTTP status code that has been reserved since the nineties, plus a payload format describing what is owed. The settlement rail underneath is stablecoin transfer on an existing chain, and the specification is open — anyone can implement either side of it.
- What does the 402 response body contain?
- A protocol version and a list of things the server will accept: the scheme, the network, the exact amount, the asset contract, the address to pay, and how long the quote is good for. A caller picks one it can satisfy. Because the price is in the response rather than a rate card, it can be computed per request.
- Is an x402 payment safe — can the server take more than the quoted amount?
- No. The signature authorises one transfer of one amount to one recipient, so the server can settle that or nothing. It cannot draw a second time on the same authorization, and a call that fails before settlement is not charged at all.
- x402 vs Stripe agent payments, L402 and prepaid API credits — when does each fit?
- Card rails assume a human cardholder and a chargeback process behind the buyer. Lightning-based schemes settle in bitcoin and need a channel. Prepaid credits mean an account, a top-up and a balance that expires. x402 fits when the buyer is software with a stablecoin balance and the purchase is a single call priced at the moment it is made.
- Which chains and wallets can I pay from with x402?
- Any wallet that can sign the transfer authorization the 402 asks for, on the networks that response lists. On BlockRun that means stablecoin settlement on either of the chains we serve, from an ordinary wallet — no custody, no deposit held by us, and nothing to withdraw afterwards.
- Who else supports x402 besides BlockRun?
- The specification is public and the ecosystem around it includes facilitators, sellers and directories that index x402-capable endpoints. We publish our own endpoints to that index so an agent looking for a capability can find and pay for ours without a human introducing the two.