A pay-per-use API for AI agents is an API where the customer is software, the price is per request or per work unit, and the money settles at the moment the request is served. No signup form, no card on file, no invoice thirty days later. The agent asks for a price, pays it in stablecoins, and gets its response.
That sounds like a small change to billing. It isn’t. It changes who can be your customer.
Agents can’t wait for month-end invoices
Every mainstream API billing model assumes a human is in the loop somewhere. Subscriptions assume someone signed up with a credit card. Metered billing assumes someone will reconcile an invoice at month-end.
An autonomous agent breaks those assumptions at once. It doesn’t have a credit card — card networks require a legal identity, a billing address, and a fraud model built around human behavior. It doesn’t have an accounts-payable department. And it often exists for minutes: spun up to complete a task, calling a dozen APIs along the way, then gone. There is no “later” in which it can settle up.
If you want to charge AI agents for API access, the billing event has to happen inside the request loop. The agent hits your endpoint, learns the price, pays, and proceeds — all machine-readable, all in one pass. Anything that requires a browser, an email confirmation, or a human decision is a dead end for this customer.
The economics that make it possible
Per-request billing was always the honest way to price an API. It just wasn’t economical. Card networks impose a floor of roughly $0.30 plus a percentage per transaction — charging a card for a $0.002 API call loses money on every request. So the industry papered over it with subscriptions and monthly invoices that batch thousands of calls into one charge.
Stablecoin rails remove the floor. A USDC transfer on a fast, cheap chain costs a fraction of a cent, which means a $0.001 charge is a viable transaction, not a rounding error swallowed by fees. If you’re new to how these transfers actually clear, start with what stablecoin payments are and why they settle in seconds.
The rails are no longer exotic, either. Stablecoins settled on the order of $33 trillion in transfer volume in 2025, and Circle — the issuer of USDC — explicitly frames stablecoins as a native payment rail for machine-to-machine commerce: programmable dollars that software can hold, send, and verify without a bank in the loop. Sub-cent fees plus instant finality gives you a pricing model that was previously impossible: charge exactly what a request is worth, at the moment it happens.
Machine-to-machine payments, from IoT dream to agent reality
Machine-to-machine payments have been promised before. The IoT wave of the 2010s imagined smart devices paying each other for bandwidth and data, and it mostly didn’t happen — devices had no practical way to hold money, sign transactions, or decide what was worth paying for.
Agents solve all three. A wallet is just a key pair; signing is a function call; and evaluating “is this response worth $0.01 to my task” is exactly the kind of judgment LLM-driven agents make constantly. Machine to machine payments crypto rails supply the missing settlement layer: a shared ledger both machines can verify independently, with no bilateral billing agreement required. M2M commerce stopped being an infrastructure problem and became a product decision — the question is no longer can a machine pay you, but how you structure the charge.
Three billing architectures for machine customers
API monetization for AI agents in practice comes down to three architectures.
1. Metered billing with periodic invoices. The classic model: issue an API key, count calls, invoice monthly. It still works when the customer is a company that deploys agents — the humans pay, the agents consume. It fails when the agent itself is the customer, because there’s no one to receive the invoice.
2. Inline per-call payment (x402). The x402 protocol, driven by Coinbase, revives HTTP’s 402 Payment Required status: the server responds with a price, the client attaches a signed payment, the server verifies and serves. It’s the purest form of micropayments for APIs — stateless, per-request, no account anywhere. The x402 spec is worth reading in full.
3. Gateway payment session per work unit. Instead of paying per HTTP call, the agent opens a payment session for a discrete unit of work — one report, one deployment, one month of a resource — pays it on-chain, and the merchant fulfills on confirmation. This adds a small amount of state in exchange for a receipt, a status lifecycle, and webhooks.
Which one fits depends on the shape of the charge:
| Metered + invoice | Inline x402 | Payment session | |
|---|---|---|---|
| Ticket size | Any, batched | Sub-cent to cents | Cents to hundreds of dollars |
| Refundability | Credit notes | Effectively none | Traceable per session |
| State | Account required | Fully stateless | One session object |
| Best for | Human-owned agent fleets | High-frequency tiny calls | Discrete work units |
These compose. Plenty of APIs will run metered billing for enterprise keys, x402 for anonymous micro-calls, and payment sessions for anything big enough to want a paper trail.
What a machine-readable checkout looks like
Whatever architecture you pick, the checkout itself has to be built for a client that cannot see. That means:
- JSON-only lifecycle. Every step — quote, payment instructions, confirmation — is a structured API response. No HTML checkout page anywhere in the critical path.
- Pollable status. The agent creates a session and polls it through a deterministic state machine:
pending → processing → sweeping → completed. Each state means one unambiguous thing. - Machine-readable diagnostics. When something goes wrong — underpayment, wrong token, expired session — the error is a typed code the agent can branch on, not a support-email suggestion.
- Signed webhooks. The merchant’s backend learns about settlement from a cryptographically signed event, so fulfillment can be fully automated without polling on the merchant side either.
This is the design brief behind agentic payments on Plaidly: the entire payment lifecycle exposed as API objects an agent can drive end to end. If your agent framework speaks MCP, the same lifecycle is reachable as tools — see how MCP payments work and the Model Context Protocol docs.
Running a pay-per-use API for AI agents on Plaidly
Here is the concrete loop, running today on Plaidly’s testnet rails — real on-chain USDC on test networks, real API, no mainnet funds at risk:
- Self-onboard a sandbox merchant with a single
curl— no dashboard visit required. You get an API key back in the response. - Create a payment session: amount, currency, accepted chains. The response contains the deposit address and everything a paying agent needs.
- Pay it. A payer agent (or you) sends testnet USDC to the session address — or uses the simulate endpoint to exercise the flow without a wallet.
- Verify. Poll the session to
completed, or receive the signed webhook, and fulfill.
The full request shapes and an agent-oriented quickstart live at docs.plaidly.io. Plaidly also exposes an x402 facilitator endpoint for payment validation; full x402 proof settlement is on the roadmap. And because it’s the same platform that handles human checkout across twenty chains, graduating from testnet experiments to production doesn’t mean re-architecting your billing.
Selling to agents means paying agents too
Per-request billing is only half of agent commerce. The moment agents are your customers, some of them are also your suppliers — an agent that resells your data, completes tasks in your marketplace, or earns referral fees needs to get paid on the same rails, with the same machine-readable lifecycle. That side has its own design constraints, covered in crypto payouts for marketplaces and agents. Build both directions and you have something genuinely new: an API business whose customers, suppliers, and settlement layer are all software.
Related reading
- Agentic payments on Plaidly — the platform surface built for machine customers
- The x402 protocol, explained — inline HTTP-native payments in depth
- MCP payments — driving the payment lifecycle from agent frameworks
- What are stablecoin payments? — the settlement fundamentals underneath all of this
- Crypto payouts for marketplaces and agents — the money-out half