The internet has a original sin, and it's not cookies or pop-up ads. It's that we never built payments into HTTP.
Think about that for a second. The protocol that runs the entire web — every page you visit, every API you call, every resource you fetch — has zero native concept of "pay for this." When Tim Berners-Lee and the early web architects designed HTTP in the early 90s, they actually anticipated this problem. They reserved status code 402: "Payment Required." It was meant to be activated later, once someone figured out digital payments.
That was 1997. Nobody figured it out. Instead, we got the web we have today: ads funding everything, surveillance capitalism tracking your every click, paywalls gating content behind $20/month subscriptions, and API providers forcing you through account creation, credit card forms, and API key management just to make a single request.
x402 finally activates HTTP 402. Almost three decades later, someone built the thing the web was always supposed to have.
The thesis: payments as a protocol primitive
Here's the core idea behind x402. What if every API, every webpage, every service on the internet could charge per request — frictionlessly, with no accounts, no API keys, no KYC? What if the cost of accessing a resource was just... part of the HTTP exchange?
And here's where it gets really interesting: what if AI agents could autonomously pay for the resources they need?
That's x402. It's an open protocol that turns HTTP 402 from a reserved placeholder into a functioning payment layer. You request something. The server tells you the price. Your wallet pays. You get the thing. All within a single HTTP round-trip.
No sign-up forms. No billing dashboards. No monthly invoices. No Stripe integration. Just money moving at the speed of an API call, settled in USDC on Base.
If that sounds simple, good. That's the point. The best protocols are the ones that disappear into the plumbing.
How x402 works — the technical flow
Let's walk through exactly what happens when x402 processes a payment. If you've ever built anything with HTTP, this will feel familiar. That's intentional.
Step 1: Client requests a resource.
Your app (or your AI agent, or your script) sends a normal HTTP request to a server. GET /api/weather?city=paris or whatever. Nothing special about the request itself.
Step 2: Server responds with HTTP 402 + payment requirements.
Instead of a 200 or a 403, the server returns a 402 Payment Required status. The response body contains a structured payment requirement: how much it costs, what currency, where to send it, and on which network. Something like: "0.001 USDC to this address on Base."
Step 3: Client signs a payment payload.
The client's wallet (could be a browser wallet, a server-side key, an agent's embedded wallet) signs a payment authorization for the requested amount. This happens locally — no onchain transaction yet.
Step 4: Client retries the request with payment.
The client sends the same HTTP request again, this time with a X-PAYMENT header containing the signed payment payload. From the client's perspective, this retry can be automatic and invisible.
Step 5: Server verifies the payment.
The server (or more commonly, a facilitator service) verifies that the signed payload is valid: correct amount, correct destination, valid signature, sufficient balance. This verification can happen offchain, instantly.
Step 6: Facilitator settles onchain.
The facilitator submits the actual USDC transfer onchain on Base. Because Base has sub-cent gas fees, this settlement costs almost nothing.
Step 7: Server returns the resource.
With payment verified, the server returns the requested resource along with a X-PAYMENT-RESPONSE header containing the settlement receipt (transaction hash, etc.).
The key insight: from the client's perspective, this entire dance can happen in what feels like a single request-response cycle. Your x402-enabled fetch wrapper handles the 402, signs, retries, and returns the final response. The payment is invisible plumbing.
Client Server Facilitator
| | |
|--- GET /resource ------>| |
|<-- 402 + requirements --| |
| | |
| [wallet signs payment] | |
| | |
|--- GET /resource ------>| |
| + X-PAYMENT header |--- verify + settle ---->|
| |<-- confirmation ---------|
|<-- 200 + resource ------| |
| + X-PAYMENT-RESPONSE | |
Clean. Stateless. HTTP-native.
The three actors
x402 has a simple actor model. Three roles, clearly defined.
The Client (buyer)
This is whoever wants to access a paid resource. Could be a human using a browser with a wallet extension. Could be a backend service with a signing key. Most interestingly, it could be an AI agent with an embedded wallet.
The client needs exactly one thing: a wallet with some USDC on Base. That's the only credential. No username, no API key, no OAuth token. Just a wallet.
The Resource Server (seller)
Any HTTP server that wants to charge for access. You add x402 middleware to your existing Express, Next.js, or Hono app, define which routes are paid and how much they cost, and you're done. The middleware handles the 402 responses, payment verification, and header management.
The server doesn't need to know anything about blockchain if it doesn't want to. It can delegate all payment logic to a facilitator.
The Facilitator (payment processor)
The facilitator is an optional but practically important third actor. It sits between the server and the blockchain, handling payment verification and onchain settlement. Think of it as the payment processor, except it's permissionless and charges no protocol fees.
Why does this role exist? Because most servers don't want to run blockchain infrastructure. The facilitator lets a standard web server accept crypto payments without ever touching a node, managing gas, or parsing transaction receipts. The server trusts the facilitator to verify and settle; the facilitator handles the chain stuff.
There's a public facilitator at x402.org/facilitator for testnet use, and multiple production facilitators are available. You can also run your own — the facilitator spec is open.
Why Base
You might be wondering: why does x402 run on Base specifically? Why not Ethereum mainnet, or Solana, or some other chain?
The answer comes down to economics and ecosystem.
Sub-cent gas fees make micropayments actually work. This is the big one. If you want to charge $0.001 for an API call, you can't settle that payment on a chain where gas costs $2. The payment would cost 2000x more than the thing you're buying. On Base, gas fees are fractions of a cent. A $0.001 payment can actually settle for less than $0.001 in gas. That's the threshold where micropayments become viable.
USDC is native on Base. Circle issues USDC directly on Base — it's not a bridged asset. This means settlement is clean and direct, no bridge risk, no wrapped token complexity.
Coinbase built x402, and Base is the home chain. x402 came out of Coinbase's developer ecosystem. Base is Coinbase's L2. The protocol was designed with Base's properties in mind: cheap transactions, fast finality, EVM compatibility.
The traction is already there. Over 75 million transactions and $24 million in volume have already flowed through x402. This isn't a whitepaper — it's a working protocol with real usage.
Base has the densest concentration of AI agents. And as you'll see in the next section, AI agents are the killer use case for x402. The agents are already on Base. The payment protocol meets them where they are.
What x402 enables
Let's get concrete. Here's what you can build with internet-native payments.
Pay-per-request APIs
The most obvious use case. Instead of selling API access through monthly plans ($29/mo for 10,000 requests), you charge per request. Weather data: $0.001 per call. AI inference: $0.01 per generation. Market data: $0.0001 per price quote.
The buyer pays exactly for what they use. No overpaying for a tier they don't fully utilize. No underpaying and hitting rate limits. Just pure usage-based pricing at any granularity.
AI agents autonomously buying services
This is the big one. An AI agent needs weather data to plan a user's trip. It needs to call a translation API. It needs to fetch premium market data. With x402, the agent just pays. No human in the loop provisioning API keys. No account creation. No credit card on file.
The agent's wallet is its universal access credential. Any x402-enabled service in the world is instantly accessible if the agent has USDC.
Micropayment paywalls
Charge $0.01 to read an article. Not $10/month for unlimited access to content you mostly don't care about. Not a free tier funded by ads that track your behavior. Just a penny per piece, paid instantly, settled onchain.
This is the business model that could have saved journalism, if the technology had existed 15 years ago. Now it does.
Machine-to-machine commerce
IoT devices paying for cloud processing. Servers paying other servers for data enrichment. Automated systems purchasing compute on demand. x402 makes all of this trivially easy because neither side needs to be human.
Proxy and aggregation services
Build a service that aggregates multiple paid APIs behind a single endpoint. Your proxy pays upstream providers via x402 and charges downstream clients via x402. You take a margin. No contracts, no partnerships, no business development calls. Just code.
Why now: the agent economy
AI agents are the reason x402 matters right now. Not in some theoretical future — right now.
Here's the problem. Today's payment infrastructure was built for humans. Stripe, PayPal, credit cards — they all assume a human is on the other end. Someone who can fill out a form, enter a credit card number, click "I agree to the terms of service," and manage billing across dozens of services.
AI agents can't do any of that. And we're about to have billions of them.
Think about what happens today when an AI agent needs to use a paid API:
- A human creates an account on the API provider's website
- The human adds a credit card or payment method
- The human purchases credits or subscribes to a plan
- The human generates an API key
- The human configures the agent with that API key
- The agent finally makes requests
Now multiply that by every service the agent might need. Weather, translation, search, compute, storage, inference — each one requires a separate human-mediated setup process. It doesn't scale. It fundamentally cannot scale to a world where agents use thousands of services dynamically.
The x402 flow for an agent:
- Agent sends a request
- Gets a 402 back with the price
- Agent's wallet signs the payment
- Agent retries with payment header
- Access granted
That's it. The agent's wallet is the only credential it needs, for every x402 service on the internet. No accounts. No API keys. No human in the loop. The agent discovers a service, pays for it, uses it, and moves on.
This is why x402 exists now and not five years ago. The agent economy creates demand for a payment protocol that machines can use natively. HTTP 402 was always the right answer — we just needed a reason to build it.
The tech stack
If you're building with x402, here's what you're working with.
SDKs
TypeScript (the most mature):
@x402/core— protocol types, encoding/decoding, shared utilities@x402/evm— EVM-specific payment signing and verification@x402/fetch— drop-in fetch wrapper that handles 402 flows automatically@x402/express— Express.js middleware for accepting payments@x402/next— Next.js middleware for accepting payments@x402/hono— Hono middleware for accepting payments
Python: x402 package — client and server support
Go: Go SDK available for server-side implementations
Payment schemes
x402 supports different payment schemes for different use cases:
- "exact" — pay a fixed amount per request. This is what's live today. The server says "this costs $0.01" and you pay $0.01.
- "upto" — pay based on actual usage, up to a maximum. Coming soon. The server says "this costs up to $0.10" and you authorize up to that amount, but only get charged for actual usage. Think: LLM inference where cost depends on output length.
Network support
- Base (EVM) — primary network, most mature support
- Solana — supported and expanding
- More networks coming as the protocol grows
Facilitators
x402.org/facilitator— public testnet facilitator for development- Multiple production facilitators available for mainnet use
- Self-hosted option for teams that want full control
What's different from Stripe and existing payments
If you're a builder evaluating x402 against Stripe or traditional payment processing, here's the honest comparison.
Zero protocol fees. x402 charges nothing at the protocol level. The only cost is Base gas fees for settlement, which are fractions of a cent. Stripe takes 2.9% + $0.30. On a $0.01 payment, Stripe's fee structure doesn't even work — their minimum is $0.50.
No minimum payments. Stripe has a $0.50 minimum charge. Many payment processors have similar floors. x402 has no minimum. You can charge $0.0001 if you want. This unlocks an entire design space of micropayments that traditional rails physically cannot support.
No accounts or KYC required. The buyer needs a wallet with USDC. That's it. No email, no password, no identity verification, no billing address. This isn't just convenient — it's a fundamental architectural difference. Every service doesn't need its own user database for billing.
Instant settlement. When a payment settles on Base, it's done. The USDC is in your wallet. Compare this to Stripe, where funds hit your bank account in T+2 days (sometimes longer). For a real-time API business, instant settlement means instant cash flow.
Works for machines, not just humans. This is the killer difference. Stripe's entire UX assumes a human with a browser. x402 is designed for HTTP clients — which includes AI agents, scripts, servers, and anything else that can make an HTTP request and sign a transaction.
Open standard, not a company. x402 is a protocol specification, not a product. Anyone can implement it. There's no vendor lock-in, no platform risk, no terms of service that can change on you. The protocol is the protocol.
Where Stripe still wins: if you're selling to consumers who pay with credit cards, Stripe is still the right choice. x402 isn't trying to replace consumer checkout flows. It's building a new payment layer for the programmable web — APIs, agents, machine-to-machine commerce, and micropayments that traditional rails can't handle.
Getting started
x402 is live on Base today. You can start building with it right now.
If you're a merchant or API provider wanting to accept x402 payments, check out our guide on how to accept x402 payments as a merchant. It walks through adding x402 middleware to your Express, Next.js, or Hono server, configuring pricing, and connecting to a facilitator.
If you're building AI agents that need to pay for services autonomously, read our guide on how to use x402 as an AI agent. It covers setting up an agent wallet, using the fetch wrapper for automatic payment handling, and best practices for managing agent spend.
The internet was supposed to have native payments from day one. HTTP 402 was the placeholder. x402 is the implementation. And Base is where it all comes together — cheap enough for micropayments, fast enough for real-time commerce, and already home to the agents that need it most.
The plumbing is finally here. Go build something on top of it.
Related guides
- Accept x402 payments as a merchant — Add pay-per-request pricing to your API or web service
- Use x402 as an AI agent — Give your agents a wallet and let them pay for what they need