Agentic payments with x402, what builders need to know about machine-paid APIs
x402 revives the old HTTP status 402 and turns it into a payment layer for AI agents. In 10 steps you understand the flow, build a paid API and let an agent pay autonomously, without an account and without checkout.
Agents have been able to call tools, write code and read APIs for a year. Paying was never possible. Every paid API demands an account, a credit card, a KYC procedure and an API key, and that is exactly the wall an autonomous agent stops at. x402 tears that wall down. Coinbase launched the protocol in May 2025, and by now the x402 Foundation carries it together with Cloudflare. The idea is almost embarrassingly simple: the HTTP status code 402 "Payment Required" has been in the web standard since the beginning and was never used. x402 turns it into a payment request that an agent answers directly inside a normal web request. We will go through this from the concept side to the MCP server.
Step 1, understand what x402 actually solves
Imagine your agent wants to access a weather API that costs one cent per query. Today that means you create an account first, store a card, buy credits and give the agent a key. Four manual steps, all before the first request. With x402 that falls away completely. The agent simply calls the API, gets back a "402 Payment Required", pays in the same breath and receives the answer. No account, no login, no session. That is the core: x402 moves payment out of upfront onboarding and into the request itself.
Step 2, think the payment flow through by hand once
Before you write a line of code, walk through the sequence in your head once, it saves you hours of debugging later. The flow has seven stations. The client sends a normal request. The server answers with 402 and puts the payment data in the response body, so amount, recipient address and accepted chains. The client builds a signed payment with its wallet. It sends the request again, this time with the signed payment in the X-Payment header. The server verifies the payment, either itself or via a facilitator. The payment settles on-chain. The server delivers the actual resource. Once you have internalised those seven steps, the rest is just tooling.
Step 3, pick the right chain and currency
x402 is chain-agnostic but does not run equally well everywhere. By far the most active deployment base is Base, Coinbase's own layer-2 chain, because gas fees there are close to zero and micro payments in the cent range only make sense at all there. Solana and Polygon are supported too. Payment is usually in stablecoins, mostly USDC, so the agent does not have to reckon with volatile token prices. To get started take Base plus USDC, that is the best documented path and the one most examples assume.
Step 4, make an API paid
On the server side x402 is surprisingly little code. In a Node environment you put a middleware in front of your route. At its core the pattern looks like this:
import { paymentMiddleware } from "x402-express";
app.use(
paymentMiddleware("0xYourRecipientAddress", {
"/premium-data": "$0.01",
})
);
The middleware takes over everything tedious, it generates the 402 response when no payment is present, verifies incoming payments and only releases the route once payment has been made. At the simplest level you do not have to do more. The npm package x402 is stable enough for real experiments, check the exact version number on npm, it changes frequently.
Step 5, understand the facilitator
The term facilitator shows up in every x402 doc and is confusing at first. A facilitator is a service that actually executes and verifies the payment on-chain, so your server does not have to do that against the blockchain itself. Coinbase runs such a facilitator, which settles the payment and even covers the gas fee for the buyer. You can also verify payments locally, but to start take the facilitator, because it takes the entire blockchain interaction off your hands. Remember the roles: client pays, server demands, facilitator settles, blockchain is the settlement layer.
Step 6, the agent side with x402-fetch
Now the buyer side. Your agent should not react to a 402 with an error but pay automatically. For that there is x402-fetch, a thin wrapper around normal fetch. You give it a wallet, and from then on it treats a 402 not as an abort but as a payment request. The wrapper builds the signed payment, sets the X-Payment header and sends the request automatically a second time. To your agent code that looks like a perfectly ordinary API call that simply works. That is exactly the point, the payment logic disappears behind the fetch wrapper.
Step 7, bring x402 into an MCP server
For the Academy the most interesting part is the MCP connection. If you have built an MCP server already, you know that tools have been free so far, whoever installs the server uses all tools for nothing. With x402-mcp, still early at version 0.1.1, you can make individual tools paid. A tool that does an expensive computation or taps a paid third-party service then demands a micro payment per call. That is a genuine monetisation layer for MCP servers that works without Stripe, without subscriptions and without user accounts. But treat the version as what it is, an early package. I would not switch it on for a product yet, for learning it is ideal.
Step 8, set limits before the agent empties the account
This is the part the marketing posts like to leave out. An agent that can pay autonomously can also pay too much autonomously. In the fourth quarter of 2025 there was the meme coin experiment PING, which abused x402 as a game, over 150,000 transactions in the first month, because people repeated the payment loop on Base hundreds of times thanks to the zero gas fees. Exactly that repeatability is the risk. Before you give an agent a wallet, set hard limits. A daily limit on the wallet, a per-request maximum, and ideally a separate wallet with only a few USDC on it instead of your main wallet. Treat the agent wallet like a prepaid card, never like a current account.
Step 9, AP2 and the bigger picture
x402 does not stand alone. It was incorporated into AP2, the Agents Payment Protocol driven by Google. That matters because it turns x402 from a Coinbase project into a more broadly carried standard, and that lowers the risk of building on something that is dead in a year. In parallel several sources report that agentic payments are moving into ChatGPT and Claude directly via MCP. You do not have to use AP2 today, but you should know that x402 is not an isolated crypto gimmick but part of a standardisation wave for machine-paid services.
Step 10, when you do NOT need x402
The most honest step at the end. x402 is a solution for a specific problem, namely autonomous machine-to-machine payment of micro amounts without an account. If you charge people 19 euros a month, Stripe is still the right tool, not x402. If your API is used by known business partners with contracts, you do not need on-chain micro payments. x402 shines where many small amounts flow between parties that do not know each other beforehand, pay-per-call APIs, paid MCP tools, data retrievals in the cent range. Do not build it in because it is new, build it in when your use case is exactly that.
What next
If you found step 7 exciting, start with your own MCP server and make just one of its tools paid first. The playbook First MCP server in 90 minutes gets you to the basics, and MCP stdio security shows what to watch out for once money is involved. If you want to go deeper into agent architecture, level 5 starting with What is an agent is the right entry point.
Source
- x402 official site and whitepaper, https://x402.org
- Coinbase Developer Platform, x402 docs, https://docs.cdp.coinbase.com/x402/welcome
- Zuplo, autonomous API and MCP server payments with x402, https://zuplo.com/blog/mcp-api-payments-with-x402
- npm packages
x402,x402-fetch,x402-mcp(as of 2026-06), the exact version numbers change frequently, check on npmjs.com before use