x402 Pay Per API Call: Let AI Agents Pay Your API

What is x402, and why does pay per API call matter now?

x402 is an open standard for paying over HTTP. It takes a status code that has sat unused in the spec for decades — 402 Payment Required — and gives it a concrete meaning: this resource costs money, here is how to pay, try again with proof of payment. The buyer settles the amount in a stablecoin, retries the request, and the server returns the data. The whole exchange happens inside the normal request/response cycle of the web.

For most of the web's history that idea had nowhere to go. Money moved over card rails that needed a human, a billing relationship, and days to settle — none of which fit a single API call worth a fraction of a cent. The change is the buyer. The fastest-growing consumer of APIs is no longer a person clicking a button; it is an AI agent calling tools, models, and data sources thousands of times to complete a task. That buyer cannot fill out a signup form or wait for an invoice. It needs to pay, programmatically, the instant it hits a paywall — which is exactly the gap x402 was designed to close.

The problem: agents can call your API, but they can't pay for it

If you run an API, a data feed, or a developer tool, your monetization options were built for human customers: a signup flow, an API key issued after someone enters a credit card, a monthly plan, and a dashboard to manage it. Every one of those steps assumes a person is in the loop, with an email, a card, and the patience to onboard.

Autonomous agents break that model. An agent orchestrating a task may want to call your endpoint once, or ten thousand times, and it has no way to enroll in your billing system on its own. So it doesn't — it skips paid APIs entirely, or a developer pre-provisions a shared key and eats the cost, or your service simply never gets called because there's no path from "agent needs this data" to "agent pays you for it." The demand is real and growing; the payment rail to capture it has been missing.

What it costs you to stay on subscriptions and API keys

Subscription pricing forces every buyer into the same shape: a recurring plan sized for a human team. An agent that needs a hundred calls this week and none next week has to commit to a monthly tier or go elsewhere. You lose the long tail of small, sporadic, machine-driven usage — which is precisely the usage that scales as the agentic web grows.

API keys carry their own tax. You build and maintain the signup, the key vault, the rate limiting, the metering, the dunning emails when a card fails. You carry chargeback risk on the card payments behind those plans, and you wait days for funds to settle while an acquirer holds them. Meanwhile the value you actually sell — a single, metered response — gets buried under an account-management layer that the buyer never wanted and an agent literally cannot use. Per-call payment removes that whole layer: the request is the purchase.

How the x402 payment flow actually works

x402 is a small, HTTP-native handshake. Nothing about it requires a browser, a redirect, or a hosted checkout page — it is designed for one program paying another. The flow looks like this:

1. An agent makes a normal request to your paid endpoint.
2. Instead of the data, the server fronting the resource replies 402 Payment Required with the price and where to send it (asset, amount, network, destination).
3. The agent's wallet pays the stated amount — a USDC transfer on Base — and attaches proof of payment to a second, identical request.
4. A facilitator verifies the payment on-chain; the server sees it's settled and the resource is returned.

Conceptually, the round trip is just:

# 1) Agent calls a paid endpoint
GET /v1/market-data HTTP/1.1
Host: api.yourservice.com

# 2) Server: pay first
HTTP/1.1 402 Payment Required
Accept-Payment: x402
X-Price: 0.01 USDC
X-Network: base

# 3) Agent retries with proof of a USDC-on-Base payment
GET /v1/market-data HTTP/1.1
Host: api.yourservice.com
X-Payment: <signed payment proof>

# 4) Verified and settled → data returned
HTTP/1.1 200 OK
Content-Type: application/json
{ "data": "..." }

Two layers make this practical. A facilitator verifies the on-chain payment and confirms settlement, so no one's code has to speak blockchain directly. And a proxy in front of your API speaks the x402 handshake on your behalf — returning the 402, collecting the proof, then forwarding the paid request to your real endpoint. Payzum is that proxy: it runs the x402 flow and integrates the settlement facilitator, so your service never has to.

How Payzum settles x402 payments to your own wallet

Here is the part that makes adoption trivial: you don't implement x402 — Payzum does. You add your existing API endpoint and the API key or bearer token Payzum should use to call it, set a price, and Payzum publishes a paid x402 URL in front of it. When an agent pays, Payzum proxies the request to your real endpoint, injecting your key, and returns the response. Your service keeps doing exactly what it already does — Payzum handles the 402, the payment, and the plumbing. It's a dashboard configuration, not an integration project, so an API provider can start serving paid agent calls immediately without changing a line of code.

Settlement stays non-custodial. When an agent pays for one of your calls, the USDC on Base settles directly to a wallet you control; Payzum coordinates the payment but never pools, holds, or controls the money — so, just like every other Payzum rail, there is no platform balance for anyone to freeze. As we cover in our non-custodial processor guide, settlement is the payment.

Base is the right home for this. It is an Ethereum Layer 2 where USDC transfers confirm in roughly two seconds and cost a fraction of a cent in gas — fast and cheap enough that paying per individual API call is economically sane, not just technically possible. Because the payment is a stablecoin transfer, it is final the moment it confirms: no chargebacks, no reversals, no card-network intermediary deciding whether your money is really yours.

You get the developer surface you'd expect around it: a REST API with API keys for your own integration, signed webhooks so each settled call can fire an event into your systems, encrypted secrets, 2FA, and a full audit log. The agentic payment is new; the operational tooling around it is the same battle-tested Payzum stack.

How to turn on pay per API call, step by step

1. Point Payzum at your API. In the dashboard, add your existing endpoint and the API key or bearer token Payzum should use to call it on your behalf. No code changes on your side.
2. Set a price and your payout wallet. Decide what a single call is worth — a fraction of a cent, a cent, more for heavy compute — and the Base wallet where USDC should land. Payzum publishes a paid x402 URL for that resource.
3. Payzum runs the 402 and proxies the call. When an agent hits the URL, Payzum returns the 402, the payment settles in USDC on Base, and Payzum forwards the paid request to your endpoint and returns its response.
4. Reconcile with signed webhooks. Each settled call fires a signed webhook into your systems for metering, analytics, and accounting — backed by 2FA, encrypted secrets, and an audit log.

There's a free tier to start: roughly the first 1,000 transactions per month are free, then around $0.001 per transaction plus gas, so the cost of accepting a payment stays well below the value of the call.

Use cases: who monetizes with x402

Pay-per-call fits anything an agent might consume on demand, where a subscription is too heavy and "free" leaves money on the table:

• Data and market APIs: sell a single price quote, a weather pull, a sports stat, or a compliance lookup for a fraction of a cent — and let agents buy exactly the calls they need, when they need them.
• AI tools and inference endpoints: charge per model call, per generation, or per enrichment, so heavy compute is paid for at the moment it's used instead of averaged into a flat plan.
• MCP servers and agent tools: wrap a paywall around a tool you expose to AI agents, so every invocation of your MCP server settles USDC straight to your wallet.
• Premium scraping, search, and retrieval: meter access to an expensive index or a curated dataset per query, with no shared API key to leak or over-use.

The common thread is granularity. When the unit of value is one response, the unit of payment should be one response too — and the buyer placing that order is increasingly an agent, not a person.

x402 pay per API call vs API keys and subscriptions

Common objections, answered

Isn't paying per call too expensive in fees and gas?

That's the reason x402 settles on Base in USDC. A transfer there confirms in roughly two seconds and costs a fraction of a cent in gas, and Payzum's per-transaction cost is around a tenth of a cent after a free monthly tier. The economics only work because the rail is cheap and fast — which is the whole point of using a stablecoin on a Layer 2 instead of a card.

Do I have to rebuild my API to support x402?

No — you don't even implement x402 yourself. You point Payzum at your existing endpoint and add your API key; Payzum sits in front as a proxy, returns the 402, settles the payment, then forwards the paid request to your service. You change no code and implement no protocol — it's a dashboard configuration, which is what lets API providers start serving agents the same day.

Is the money safe if Payzum is in the middle?

Payzum is non-custodial. The USDC settles directly to a wallet you control; Payzum verifies and coordinates the payment but never holds it. There is no Payzum balance to freeze, and on-chain finality means a settled call can't be clawed back.