USDC on Base per Request: The Rail That Makes Machine Payments Work

Why per-request pricing had nowhere to settle

Every API team that has looked at agent traffic has had the same idea and the same problem. The idea: stop selling seats and plans, and just charge for what a caller consumes — a cent for a lookup, a fraction of a cent for a cache hit, more for an expensive inference. The problem: there was nowhere to put the money.

Metering is the easy half. You already count requests; every gateway does. The hard half is the movement of value. To collect $0.002 you historically had to do one of three things — none of which fit a machine caller:

• Accumulate and invoice. Meter usage, wait for the month to close, send a bill, chase it. That's a credit relationship, and credit requires knowing who the customer is, believing they'll pay, and having a way to collect if they don't. An autonomous agent that appeared four minutes ago and will be shut down tomorrow is not a credit-worthy counterparty.
• Take a card up front. Which means a signup, a form, a human with a wallet in their pocket, a 3-D Secure challenge, and a fixed fee per authorization that dwarfs the purchase. A card network is a fine way to move $40. It is a comically bad way to move $0.002.
• Prepaid credits. The compromise almost everyone ships. It works — but you've now built a ledger, a top-up flow, a refund policy, a dunning system, and a float you're holding on someone else's behalf. You wanted to sell an API and you became a bank.

So the price of a request kept getting rounded up into a subscription. Not because subscriptions are the right shape for machine demand, but because that was the smallest amount of money the plumbing could carry. The rail dictated the pricing model.

USDC on Base per request is what changed that. Not a new billing feature — a settlement layer where a sub-cent payment costs less to move than it's worth, and clears fast enough to happen inside the request that triggered it.

What the rail gap actually costs an API business

The cost isn't a line item, which is why it goes unnoticed for years. It shows up as three distortions.

You price for the wrong buyer. A $49/month floor is a rational response to a $0.30 authorization fee — it's the smallest ticket that doesn't lose money. But that floor is invisible to the caller who wanted eleven requests. It doesn't convert them at a lower price; it makes them not exist. You never see the demand you priced out, so it never appears in a dashboard as a loss.

You pay for traffic that never pays you. Free tiers exist to solve the same problem from the other side: you can't collect small amounts, so you give small amounts away. Then agents discover the free tier, and it stops being a marketing budget and becomes a compute bill. Rate limits are the usual response — you throttle your most enthusiastic non-customer rather than charging them, because there's no mechanism to charge them.

You lose the buyer who arrives ready. This is the expensive one. An agent that hits your endpoint with a funded wallet is a customer with cash in hand and no interest in negotiating. If your only door is a signup form and a card, that buyer leaves. It doesn't file a support ticket or fill in a churn survey. It picks whichever endpoint answered with a price it could pay, and never comes back.

Why the traditional rails structurally can't do this

It's tempting to read the fee tables and conclude that card networks are simply expensive. The real answer is more useful: they're built for a different job, and every part of them reflects it.

A card payment is reversible by design. The consumer protection you get as a cardholder — the ability to dispute a charge months later — is the product. That reversibility has to be funded, monitored and adjudicated, and the machinery costs a fixed amount per transaction whether the transaction is $3 or $3,000. That fixed floor is precisely what makes a $0.002 payment impossible: the overhead is a thousand times the payment.

A card payment is also custodial and delayed. Funds route to an acquirer, sit in a merchant account, and land in your bank one to three days later — after reserves, holds, and a risk team that may decide your traffic pattern looks unusual. High-frequency, low-value, machine-originated traffic is exactly the pattern conservative underwriting flags.

And a card payment is identity-first. It assumes a named human with a billing address and a bank relationship. An autonomous agent has none of those. It has a wallet, a budget, and a task. Asking it to complete a signup flow isn't a UX problem you can polish away — it's a category error.

Bank transfers fail on latency and minimums. Invoicing fails because it's credit. What per-request pricing needed was a rail that is final at the moment of payment, cheap enough that the fee doesn't eat the payment, fast enough to happen mid-request, and open to a counterparty with no identity beyond a wallet address. That combination didn't exist on traditional infrastructure. It exists on a stablecoin L2.

Why USDC on Base per request, specifically

"Pay in crypto" isn't an answer — most chains and most tokens are wrong for this. Per-request payments impose four hard constraints, and Base plus USDC is the combination that satisfies all four at once.

1. The fee has to be smaller than the payment

This is the binding constraint and it eliminates most options immediately. A payment of a fraction of a cent on Ethereum mainnet is absurd — the gas alone can exceed the purchase by orders of magnitude. Base is an OP Stack Layer 2 built by Coinbase; since Ethereum's Dencun upgrade introduced blob storage, the cost of a stablecoin transfer there has typically sat well under a cent. That's the difference between a per-call payment that clears a margin and one that's theatre.

2. It has to confirm inside a request's patience

A payment that settles in ten minutes can't happen during an HTTP call. Base confirms in roughly two seconds, which fits inside the timeout budget of most API clients. That's what allows the whole exchange — request, 402, payment, retry, response — to be one interaction rather than an onboarding flow. On Payzum's other supported networks the same property holds: Solana confirms in about 0.4 seconds, Polygon in about two.

3. The unit has to be a dollar

If you price a call at "0.000004 ETH", you've quietly turned every customer into a currency trader and yourself into one too. USDC is dollar-denominated, so $0.002 is $0.002 at quote time and at settlement. Circle issues native USDC on Base — worth noting, because the older bridged token (USDbC) still shows up in some wallets under a similar label. Native USDC is the one with direct Circle redemption and the deeper liquidity, and it's what agent tooling defaults to.

4. The buyer must be able to pay without holding gas

This is the detail that makes machine payments practical, and it's the one most explainers skip. USDC implements EIP-3009, the transfer-with-authorization standard. The buyer signs a typed-data authorization — from, to, value, validity window, a random nonce — and a third party broadcasts it on-chain and pays the gas. Per the x402 exact-EVM scheme, that broadcaster cannot modify the amount or the destination; it only relays a signature it can't rewrite. So an agent holding nothing but USDC can pay, and the signature is worthless to anyone who intercepts it — it pays you, at your price, or it does nothing.

Put those four together and you have the actual reason USDC on Base per request became the default shape of agent payments: it's the intersection where sub-cent value can move, fast, in dollars, from a counterparty with no bank.

How Payzum lets you charge on this rail without writing code

Everything above is the rail. The gap most teams hit is the distance between "this rail exists" and "my endpoint is on it": you'd need to speak the x402 protocol, produce a valid 402 with payment requirements, verify signatures, talk to a facilitator, confirm settlement, and only then do the work. That's a payments project bolted onto an API business.

Payzum removes that project. It sits as middleware in front of your existing endpoint. You configure three things in a dashboard — your endpoint URL, the API key or bearer token it expects, and a price — and Payzum publishes an x402-enabled URL for it. When an agent calls that URL, Payzum returns the 402 with payment details, the agent pays USDC on Base, the payment settles through an external facilitator (currently Coinbase's), and Payzum then proxies the paid call to your real endpoint with your key attached, returning your response to the agent.

Two things about that flow matter more than the rest:

• Your code doesn't change. Your service keeps receiving ordinary authenticated requests from a client it already trusts. No SDK, no protocol implementation, no migration. An API provider can start serving paying agents the same day.
• The money never touches a Payzum balance. Settlement is non-custodial — USDC lands in a wallet whose keys you hold. There's no account to be frozen, no payout schedule, no reserve. The settlement is the payment.

To be precise about roles, because it's the thing people get wrong: Payzum is not the facilitator. The facilitator is the party that verifies the signed authorization and broadcasts it on-chain; today that's Coinbase's. Payzum is the proxy layer that lets your endpoint speak x402 without you implementing any of it.

How it works, step by step

1. Point Payzum at your endpoint. Give it the URL you already serve, plus the API key or bearer token it should inject when forwarding paid traffic. Your existing auth stays exactly as it is — the key lives in Payzum's encrypted secret store, never in the agent's hands.
2. Set a price per call, in dollars. Pick a figure per route: a fraction of a cent for a cheap lookup, a few cents for something that costs you inference or an upstream API fee. The price is quoted in USDC, so what you set is what settles. You can price routes differently.
3. Add the wallet that gets paid. A Base address you control. Every settled payment lands there directly — there's no Payzum-held balance in the path, and no withdrawal step to remember.
4. Publish the x402 URL and let agents find it. Payzum returns the 402 Payment Required with your price and payment details; x402-aware agents and wallets handle it automatically, pay, and retry. Signed webhooks and the audit log give you a per-call record for reconciliation.

From the agent's side, the whole exchange looks like this:

GET /v1/enrich?domain=acme.com
→ 402 Payment Required
   { "price": "0.004 USDC", "network": "base", "payTo": "0x…", "scheme": "exact" }

# agent signs an EIP-3009 authorization, retries with the payment header
GET /v1/enrich?domain=acme.com   [X-PAYMENT: <signed authorization>]
→ 200 OK   { …your endpoint's normal response… }

No account. No API key exchanged with the caller. No invoice. The call and the payment are the same event — which is the property that makes the whole model work. If you want the protocol-level walkthrough, we covered it in x402: pay per API call; the comparison with seat and key billing lives in x402 vs API key billing.

Use cases: where per-request USDC settlement earns its keep

The rail matters most where the value of a single call is small, the volume is high, and the caller is transient. Four concrete shapes:

• A data enrichment API charging per lookup. Company data, WHOIS, geocoding, an address validator. Each call is worth a fraction of a cent and today gets bundled into a plan nobody on the long tail buys. Priced at $0.004 per call on Base, the tail becomes revenue instead of a rate-limit rule — and a research agent running 20,000 lookups pays $80 without ever creating an account.
• An inference or model endpoint with real marginal cost. When every call burns GPU time, free tiers are a direct subsidy and flat plans invert your unit economics — your heaviest users are your least profitable. Per-request USDC makes revenue track cost per call, at the granularity the cost actually occurs.
• An MCP server or agent tool. The Model Context Protocol made your tools discoverable by every agent framework and shipped with no billing layer at all. x402 sits underneath at the HTTP level, so a paid tool call works without the agent needing an account with you — see monetizing an MCP server with x402.
• A premium lane on an existing free API. Keep the free, rate-limited endpoint for humans and hobbyists. Publish a paid x402 URL alongside it with no throttle and priority routing, for callers who'd rather pay cents than wait. Same backend, two doors, and the expensive traffic finally funds itself.

The common thread: in each case the buyer showed up ready to pay an amount too small for any conventional rail to carry. That's the entire opportunity — and it's also why the choice of chain and token isn't a technical footnote. It is the business model.

USDC on Base per request vs the alternatives — side by side

Common objections, answered

"Isn't a Layer 2 riskier than settling on Ethereum mainnet?"

It's a different trade-off, not a strictly worse one, and it's worth being precise. Base is an OP Stack rollup that posts its data to Ethereum; you get L1 data availability with L2 cost and speed. For per-request payments the alternative isn't "settle on mainnet instead" — mainnet gas makes a sub-cent payment structurally impossible, so the real alternative is "don't collect at all." If your risk posture calls for it, sweep accumulated USDC to wherever you want it to live; because settlement is non-custodial, that's your decision and your key, not a withdrawal request to us.

"We don't want to hold crypto on the balance sheet."

The exposure here is narrower than it sounds. USDC is dollar-denominated, so what accumulates in your wallet is a dollar balance, not a volatile position — the volatility question that applies to accepting BTC or ETH doesn't apply the same way to a stablecoin. Payzum is crypto-only and doesn't settle to fiat bank accounts; what it does give you is settlement in a dollar-pegged asset, in a wallet you control, with optional auto-conversion to USDC or USDT if a caller pays in something else. Accounting and treasury policy stay yours — talk to your accountant about how you recognise it.

"Our traffic is mostly humans with API keys. Do we have to migrate?"

No, and you shouldn't. This is additive. Your existing keys, plans and customers keep working exactly as they do — Payzum's proxy sits in front of a separate published URL. Agents pay per call on that lane; your human customers never see it. Most providers we talk to run both indefinitely, because the two buyers want genuinely different things: humans want predictable monthly cost, machines want to pay for exactly what they used and nothing more.

"What happens if an agent pays and my endpoint then fails?"

Worth designing for, and the honest answer is that this is a policy decision you make, not something the protocol decides for you. Payment and delivery are tightly coupled — the paid call is proxied immediately — but upstreams have bad days. Signed webhooks and the audit log give you a per-call record of what was paid and what your endpoint returned, which is the raw material for whatever you decide: a credit, a retry allowance, or a health check that stops advertising a price when your service is degraded. It's the same reasoning any metered API applies to failed requests; the difference is you have on-chain evidence of every payment.