x402 Use Cases
x402 turns any HTTP endpoint into something you can charge for per request, settled instantly in USDC. Here's what people actually build with it.
What is x402 used for?
x402 is used to charge for digital access per request, settled instantly in USDC. The main use cases are AI agents paying for tools and data autonomously, pay-per-call APIs instead of subscriptions, monetizing MCP servers, metered content and paywalls, paid model inference, and general machine-to-machine commerce.
AI agents paying for tools & data
An autonomous agent hits a paid API, pays a few cents in USDC, and gets the result — no API key signup, no human in the loop. This is the flagship use case: software paying software.
Example: A research agent pulls live market data from a paid endpoint mid-task, pays the invoice itself in USDC, and continues — no developer had to pre-provision an API key.
Pay-per-call APIs
Charge per request instead of selling monthly subscriptions and managing API keys. Great for niche or expensive endpoints where usage is bursty.
Example: A weather or geocoding API that gets hit unpredictably charges $0.001/call instead of forcing every caller onto a $29/mo plan they may barely use.
Monetizing MCP servers
Put a price on individual MCP tools so any agent that connects can pay-as-it-goes for what it actually calls.
Example: An MCP server exposes a "web search" tool at $0.002/call — any agent that connects pays only for the searches it actually runs.
Metered content & paywalls
Sell a single article, dataset, or file for a micro-amount without forcing readers to create an account or start a subscription.
Example: A research report behind a $0.25 x402 paywall instead of a "sign up for our newsletter" gate — one payment, instant access, no account.
Paid inference / model access
Wrap an LLM or model endpoint so callers pay per inference, settled instantly in USDC.
Example: A fine-tuned model endpoint charges $0.01/request so anyone (or any agent) can call it without a subscription or a shared API key to manage.
Machine-to-machine commerce
Devices, scrapers, and backend services that need to transact autonomously — micropayments without cards or invoices.
Example: A backend crawler pays a per-page fee to a rate-limited scraping-friendly API instead of getting blocked, with no invoice or NET-30 terms involved.
How this compares to the old way
See it in the wild
We track 1.5k+ open-source projects across these use cases — facilitators, gateways, paid MCP servers, SDKs, and starter kits. Browse the full directory →
Frequently asked questions
What is x402 used for?
x402 is used to charge for digital access on a per-request basis, settled instantly in USDC. The main use cases are: AI agents paying for tools and data autonomously, pay-per-call APIs (instead of subscriptions and API keys), monetizing MCP servers, metered content/paywalls without accounts, paid model inference, and general machine-to-machine commerce.
Why use x402 instead of a normal subscription?
Subscriptions require signup, billing, and API-key management, and they don’t fit software that needs to pay other software on the fly. x402 lets a caller pay a few cents per request with no account — ideal for autonomous agents, bursty usage, and one-off purchases where a monthly plan makes no sense.
Is x402 only for AI agents?
No. AI agents are the headline use case because they can pay autonomously, but x402 works for any pay-per-use scenario: APIs, datasets, single articles, model inference, and machine-to-machine services. Any HTTP endpoint can require payment.
What kinds of projects are building on x402 today?
The open ecosystem already spans facilitators, payment gateways, SDKs, MCP integrations, and starter kits. We track 1.5k+ such projects in the mpp.best directory, which you can browse by category to see real implementations across each use case.
How small can an x402 payment be?
Because x402 settles USDC on low-fee networks like Base, payments of a fraction of a cent are practical. That’s what makes per-request and per-inference pricing viable where card fees would make micro-charges impossible.
Do I need to change my API to support x402?
No rewrite is needed — x402 sits in front of an existing route as middleware (or a manual 402 check). The route’s own logic stays the same; you’re only adding a payment check before it runs. Most integrations are a few lines: install the middleware, set a price and a receiving wallet, done.
What happens if a payment fails or the agent has no funds?
The request simply gets a 402 with the payment requirements and never reaches your handler — nothing is served, and nothing needs refunding, because settlement happens before the response. This is simpler than card payments, where a failed charge can arrive after you’ve already done work.
Build one: tutorial · sell an API with x402 · agent payments