What is x402?
x402 is an open standard that lets any website or API charge for access directly over HTTP.
A client that gets a 402 Payment Required response can pay and retry inside the same conversation:
with a wallet signature instead of an account, a card form, or an API key.
The problem x402 solves
Paying online today means forms: account, identity proofing, subscription, API key. Each step exists because classical charging means a long-lived relationship. But two shifts break that model: prices too small for card rails (charge half a cent per call), and buyers who are machines (an agent cannot fill a signup form; it can sign a message with a wallet).
- Create an account with the API provider. Setup time and forms.
- Add a payment method. Identity verification, then a wait for approval.
- Prepay credits or start a subscription. Money committed to an estimate: overpay, or run dry.
- Manage an API key. Store it, rotate it, accept the leak risk.
- Actually pay. Slow settlement, fees, and the possibility of chargebacks.
- Send a normal HTTP request. The server answers 402 with a machine-readable price.
- Sign the payment with a wallet and retry. Signature in, no signup, no approval queue.
- Get the answer. No account, no key, no committed estimate.
So today's paid APIs mostly serve humans with monthly plans while machines watch from the sidelines. Usage billing at machine speed needs exactly the mechanism above.
How a payment flows
The only added hop versus a normal API call: the reject-and-retry at the start. Everything else happens between server, facilitator and chain.
Drag to pan the diagram →
Run a payment, click by click
Three tabs, one payment. Each tab shows exactly what flies over the wire.
>>> GET /weather
<<< 402 Payment Required
<<< PAYMENT-REQUIRED:
{
"scheme": "exact",
"network": "eip155:8453",
"amount": "1000",
"asset": "USDC",
"payTo": "0x15C7...Cd"
}The server names its price in machine-readable form. Not an invoice page, not a PDF: a JSON offer listing scheme, network, amount, asset and receiver. A client that already knows the price skips this step.
>>> GET /weather
>>> PAYMENT-SIGNATURE:
{
"scheme": "exact",
"network": "eip155:8453",
"payload": {
"signature": "0x8fe...9a",
"authorization": "move exactly 1000 USDC-units to 0x15C7...Cd"
}
}The client picks an offer and signs it with its wallet: an authorization that lets exactly the stated amount move to exactly the stated receiver. Nothing has moved yet. The signature is the money order.
<<< 200 OK
<<< PAYMENT-RESPONSE:
{ "success": true, "txHash": "0xad13...77f" }
{ "weather": "sunny", "temp_c": 21 }The server verifies the signature, settles on the chain (usually through a facilitator), and answers with the content plus the receipt. From the client's side the whole thing was one retry.
Three headers carry the whole conversation
Each rides a standard HTTP request or response as base64-encoded JSON, clean through proxies and load balancers.
PAYMENT-REQUIRED 402 response, server to client the offer: price, asset, network, destination
PAYMENT-SIGNATURE retry request, client to server the signed payment payload
PAYMENT-RESPONSE final answer, server to client the settlement receipt, e.g. the transaction hashKey concepts
Three ideas do most of the work in x402: schemes, facilitators, and the network layer underneath.
A scheme is a logical way of moving money. The server picks one (or more) per route; the client picks from the offered list.
exact
A fixed price per call. The buyer authorizes exactly the advertised amount. This is the classic pay-per-request scheme and what almost every live endpoint uses: pay $0.005 once, get the answer once.
upto
Usage-based with a ceiling. The buyer authorizes a maximum per request, and the seller settles the real usage below that cap. It fits compute time, tokens, and bandwidth, where the final cost is only known after the work is done.
batch-settlement
Built for many tiny charges on EVM chains. The buyer deposits into an escrow contract once, signs one off-chain voucher per request, and the seller redeems a whole batch on-chain later instead of paying settlement cost per call.
Facilitators
- ✓Verify and settle for the server. Optional middle service that removes blockchain plumbing: no node, no gas wallet, no retry logic.
- ✓Never holds funds. It executes the buyer's signed authorization; amount and destination are pinned by the signature, so neither facilitator nor server can redirect the money.
- ✓Swappable, anyone can run one. But heads up: the public facilitator at x402.org is testnet-only. Production means a managed provider, your own facilitator, or settling in your own server.
Networks and tokens
Networks use CAIP-2 ids, e.g. eip155:8453 for Base mainnet. Chains the standard speaks today:
- ✓Any ERC-20 on EVM via
EIP-3009, orPermit2as fallback; any SPL token on Solana. USDC is the common case. - ✓Gasless for buyers. The facilitator sponsors the gas; the buyer only signs.
- ✓V2 is current (CAIP-2 plus the three headers above). V1's
X-PAYMENTstays readable while the ecosystem migrates.
What it buys you
Condensed down, the standard sells itself through five properties. They all hold by design, not by policy of a single company.
Zero protocol fees
The standard itself charges nothing. The buyer pays the settlement network's normal cost, and on fast chains that stays at a fraction of a cent.
Zero wait
Payments become final at chain speed. No settlement windows, no invoicing, no chargeback periods.
Zero friction
No account, no signup form, no identity check, no API key. A request and a wallet signature are the whole onboarding.
Zero centralization
Anyone can implement or extend the protocol, and facilitators are swappable. No single party holds the keys to the system.
Zero restrictions
A neutral standard, not tied to one network or token. Stablecoins are the common case today; other assets and even fiat rails can plug in the same way.
Why the combination matters
Fractions of a cent settle in seconds, so per-request prices become viable: a $0.005 report, a $0.10 image, a $0.001 lookup. Onboarding is one request, so strangers become customers instantly. And because signing is cryptography instead of form-filling, machines are first-class buyers.
The trust model rounds it off: the buyer signs, the chain executes exactly that instruction, and nobody in between can redirect or overdraw.
Where x402 stands today
About a year and a half in, x402 is no longer an experiment. It has a foundation, a large member roster, reference SDKs in TypeScript, Python and Go, and real money flowing through it every hour.
Figures from the official site, trailing 30 days as of July 14, 2026. The Solana Foundation attributes nearly 65% of that volume for this year to Solana rails (statement from the April 2026 announcement). The reference repository shows roughly 6,500 stars and 1,900 forks as of August 2026.
Governed by 40 organizations
The x402 Foundation stewards the protocol under Linux Foundation governance. Membership at the operational launch:
The large public indexes where agents and buyers find payable endpoints.
The crawled index of record for the ecosystem, tracking the endpoint population on Base and Solana. Where most agents look services up.
Agentic.Market →A service directory built on the CDP Bazaar, the catalog of the largest facilitator ecosystem in x402.
ampersend.ai/discover →A discovery surface built for agentic commerce: find services an agent can call and pay on its own.
Continuously updated, probe by probe: the live ecosystem report · raw stats as JSON · facilitator leaderboard
How x402 Trust fits in
Directories prove an endpoint exists. Probes prove it answers. Neither proves payment works, nor that it still works tomorrow. x402 Trust closes that gap: a 24/7 monitoring and scoring service sitting on top of the whole ecosystem.
What the monitor answers before a buyer pays
- ✓Is it reachable and spec-clean? Continuous polite probes parse every listed endpoint's 402 envelope.
- ✓Does real money settle? Read straight from the chain as genuine USDC transfers on Base and Solana; the one signal that cannot be faked.
- ✓Did anything change? Price, receiver wallet, spec compliance. Flags need two sightings six hours apart, so an outage never manufactures an alarm.
- ✓And in one number? A deterministic trust score between 0 and 100, graded A to F.
The access model rhymes with the ecosystem it watches: paid reports are sold per call over x402 itself, so every trust report doubles as a live demo of the flow above.
Free surfaces: ecosystem report · leaderboard · endpoint pages · failure modes
Whether an endpoint delivered what it advertised after payment. That judgment only exists at realistic cost between buyer and seller. A trust score is strong evidence that paying works, not a promise that the delivery will be good.
Get started
If you sell an API
Charging for a route is middleware, roughly one line per framework, plus a receiving address.
npm install @x402/core @x402/evm @x402/expressapp.use(
paymentMiddleware({
"GET /weather": {
accepts: [...], // networks / schemes you want to support
description: "Weather data", // what your endpoint does
},
}),
);Equivalent flows exist for Fastify, Hono and Next, for Python (pip install x402) and for Go.
Add @x402/svm to also accept Solana.
If you (or your agent) buy
Wrap the HTTP client once. 402s get paid from the registered wallet and retried; application code stays untouched.
npm install @x402/core @x402/evm @x402/axiosimport { x402Client, wrapAxiosWithPayment } from "@x402/axios";
import { ExactEvmScheme } from "@x402/evm/exact/client";
const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(signer));
const api = wrapAxiosWithPayment(
axios.create({ baseURL: "https://api.example.com" }), client,
);
const response = await api.get("/paid-endpoint"); // 402s handled for youAgents work the same way: wrap the client, sign with the agent's wallet, point it at any listed endpoint.
Things to know before you build
Four production realities, each seen or documented in the live ecosystem. Worth five minutes before shipping.
Payments are final
The exact scheme is a push payment: once it settles, only the seller can return money with a normal transfer back. There are no chargebacks. The batch-settlement scheme on EVM owns cooperative refunds from its escrow, but plain per-call payments do not.
The public facilitator is a testnet tool
The facilitator hosted at x402.org covers testnets (Base Sepolia, Solana Devnet, and others) and is meant for development. A production service picks a production facilitator, runs its own, or handles verification and settlement inside its own server.
Solana needs duplicate-settlement protection
If a client submits the same payment to settle twice before the first one lands, a naive implementation can deliver twice for one payment. The reference SDKs ship a short-lived SettlementCache that rejects the duplicate; a hand-rolled server has to rebuild the same protection.
Small config errors break every payment
The EIP-712 signing domain must match the token exactly: mainnet USDC signs as "USD Coin", while the Base Sepolia test token signs as "USDC". Swapped values make every customer payment fail signature recovery. More cases like this, found in live monitoring, are documented on the failure-modes page.
The full taxonomy of what a valid 402 does not prove keeps growing: failure modes from 24/7 monitoring.
Sources and further reading
Everything above traces to one of these. Dates in the copy refer to the versions read while writing this page.
- x402.org
- Developer docs
- GitHub repo and specs
- Whitepaper (PDF)
- Linux Foundation: operational launch (July 14, 2026)
- Linux Foundation: foundation announcement (April 2, 2026)
- Quickstart for sellers
- Quickstart for buyers
- Wikipedia: X402
- Slack community