Council Post: Why Agentic Payments Involve More Than Pay-Per-Call
Shawn Yu, ROZO Co-founder, building Visa Layer for Stablecoins.gettyThe payment industry is converging on a compelling idea: AI agents should pay for APIs and data without waiting for a human to type a card num...
Shawn Yu, ROZO Co-founder, building Visa Layer for Stablecoins.
getty
The payment industry is converging on a compelling idea: AI agents should pay for APIs and data without waiting for a human to type a card number.
Pay-per-call is one useful way to do that, particularly when an agent meets a new provider. But this is only one option. For instance, another model may be both familiar and preferred by users: Fund a balance, meter usage and settle the accumulated amount later.
Based on my role as a cofounder in the digital payments space, let’s look at the different ways the payments industry is approaching this question.
Why The Price Of An AI Request Often Does Not Exist Yet
Consider a large language model API. When a request begins, the provider can count the input tokens. However, it still cannot yet know the output length, how much reasoning the model will perform, whether it will call a tool or whether a retry will be required.
While a provider can bound the worst case with an output limit, that limit is itself a product compromise. The true price is known only after the work is done.
A one-call, fixed-price design therefore forces an awkward choice: Charge a price that is usually wrong, price for the worst case or cap output tightly so the initial quote stays valid. Each option weakens the promise of usage-based pricing.
There is a third option: Authorize a maximum, then capture only the measured amount. However, problems with this model grow as services evolve. A provider may add a premium model, change input-to-output ratios, introduce cached-token discounts or bill tool execution separately. If the payment protocol assumes an exact price before the request, product design starts bending around the payment primitive.
Three things that are collapsed should stay separate—authorization (the ceiling the buyer approves), metering (what was consumed) and settlement (when value moves with finality).
Micropayment Economics Are Not Micropayment UX
Protocols such as x402 make a real contribution to solving these challenges. In this model, a server returns an HTTP “402 Payment Required”; the client then attaches payment credentials and retries. This works elegantly for an agent meeting a new seller, buying a discrete item or making an infrequent call without an account.
However, x402 defines how a payment is requested, not how often it must settle on-chain, which is a scheme and implementation choice.
The ability to settle 10 cents does not mean a buyer wants to experience every 10-cent event as an independent purchase. We already load transit cards, buy cloud credits, keep app-store balances and review one monthly mobile bill. We care about a budget boundary—$1, $10, $100—while expecting the system to meter smaller units accurately.
To meet this desire, an agent should be able to receive a $10 budget, make hundreds of calls and expose a real-time usage log the user can inspect or revoke at any time. What the user likely does not want is a new payment ceremony per request.
How A Session Can Be A Better Primitive
For repeated usage, a better mental model might be a bar tab, not a turnstile, where the buyer deposits funds or authorizes a maximum. The service meters actual consumption, and each commitment updates the cumulative amount. At the end—or, at a time or risk threshold the provider chooses—the parties settle once, and unused funds stay with the buyer.
There are already a few examples of this model.
Stripe and Tempo’s Machine Payments Protocol supports both a one-time charge intent and a session intent, where a buyer funds a unidirectional channel once and signs cumulative off-chain commitments as usage grows.
The bitcoin-based Lightning Network shows both sides: Many payments can occur before final settlement, and routing means a payer needs no direct channel with every recipient. However, liquidity, uptime and channel state remain real operational burdens.
Cashu adds prefunded bearer e-cash: This enables many small payments without a conventional per-user account history. However, it comes at the cost of trusting a mint and risking loss. Channels and e-cash are optimizations, not universal replacements for a stateless payment.
These architectures fit variable-cost AI because price discovery happens alongside delivery. A model streams output while the meter advances. A data service charges by bytes returned. The seller still controls risk through limits, incremental commitments or closing the channel.
Dynamic Pricing Needs Private Memory
Another large opportunity, one that my company and others in this space are trying to solve, is letting a payment relationship improve over time without turning every agent into a surveillance target.
An agent that has bought a data feed thousands of times deserves a lower unit price, a larger ceiling or less frequent settlement. Today, the easiest way to recognize that customer is to link every request to one account or wallet, but earning loyalty means exposing unrelated activity.
A better system might be to let an agent prove only what the seller needs: that it crossed a usage threshold, kept a funded relationship and settled reliably. Cashu solves private spending but removes the signal merchants use to recognize loyalty.
The unsolved problem is combining private bearer payments with selective proof of relationship—enough continuity to earn a discount, not enough linkability to reconstruct every purchase. Sessions and channels are a good place to build it, and doing so creates a new business model: Start stateless, graduate to a metered session, earn better terms over time.
Design For Three Modes, Not One
A practical stack should support at least three of these modes.
Use an immediate charge for a discrete, known-price purchase or a first interaction with an unfamiliar provider—x402’s home ground. Use authorize-maximum, capture-actual when the final cost of a one-time request is unknown.
Use a funded session or channel for recurring, variable usage: inference, compute, storage, data feeds.
Sessions should not be universal: Prefunding ties up capital and creates provider exposure. The payment mode should follow the relationship and change as it changes. The policy layer matters as much as the rail—maximum spend per session, rate limits, approved merchants, auto top-ups, immediate revocation.
The best systems will authorize at the level humans care about, meter at the level machines consume, reveal only what the relationship requires and settle at the level the economics justify.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?