Most Agent Payments Won't Run on Cards

When people say AI agents are going to need payment infrastructure, the picture most of them have in mind is a card. That’s understandable, because it’s where the visible activity is. Mastercard has launched Agent Pay, a virtual card an AI agent can check out with, carrying spending limits and retailer restrictions. Visa is pushing its own Intelligent Commerce programme to define the standards for the same thing. I wrote about that race, and about how few shoppers currently trust it, in agentic checkout is being built faster than anyone trusts it.

That is one version of agent payments: software shopping on behalf of a person, at a merchant that already accepts cards. I think it’s the smaller version. The larger one is agents paying other agents, and paying for the services they use to get work done, and I don’t expect most of that to run on card rails at all.

My view: stablecoin rails, not card networks

I’m a big believer that crypto itself and stablecoin rails themselves are definitely going to be taking over from the card networks. That’s an opinion, not a forecast I can prove, and there are good reasons to disagree with it, which I’ll come to. But it’s the view I hold, and agents are where I expect it to show first.

The reasoning comes down to what each rail was designed around. A card payment is organised around a cardholder: a person with an account at an issuing bank, whose authorisation is the question the whole system exists to answer. Authentication at checkout asks that question before the payment. The dispute and chargeback process asks it afterwards. When Mastercard builds a card for an agent, it keeps that structure and places the agent inside it. The agent gets a constrained credential, issued for a narrow purpose on behalf of the person it’s shopping for, and that person is still the one the system is really dealing with.

That works for the shopping case, where there is a person and a purchase they asked for. It fits much less naturally when there’s no shopper anywhere in the transaction.

Let’s imagine a situation. An agent doing research work pays a data service each time it pulls a record, many times a day, in small amounts, and the data service on the other end is itself run by software. There is no checkout and no cardholder making a decision in the moment. Nobody would recognise any single one of those payments on a statement, and nobody is meant to. A stablecoin transfer suits that shape of spending better than a card does. An agent can hold a wallet address directly. A payment in USDC, a dollar-pegged stablecoin, is a transfer from one address to another, and the record of it sits on a public chain rather than inside any one company’s systems.

That last property gets far less attention than it deserves in the card-centred conversation, and it’s the one I want to spend the rest of this piece on.

A public record is not the same as a usable one

On card rails, the record of what an agent spent lives with the issuer and the network, and you see it the way they choose to show it to you. On a public chain, every payment an agent makes is visible to anyone who looks the wallet up. For a single wallet making a handful of payments, that is close to full visibility at no cost.

It stops being enough once there are several agents, each with its own wallet, spread across more than one chain. A wallet’s public history is a list of transfers. It doesn’t say which agent a payment belongs to, or whether that agent has already gone past the budget someone had in mind for it. Getting from the raw record to an answer means pulling activity from every wallet on every chain, combining it into one view, attributing each payment to the agent that made it, and comparing the running total against a limit. None of that is hard in principle. It is tedious enough that, without something doing it automatically, nobody does it until a number already looks wrong.

This connects to an argument I’ve made elsewhere on this site, that an agent’s self-report is not evidence. An agent describes a finished job in the same confident tone whether the job went well or not, so the check has to come from somewhere other than the agent. Spend on a public chain is an unusually clean case of that principle, because the independent record already exists and the agent can’t edit it. What’s missing is getting that record in front of a person, attributed to the right agent and totalled against the right budget, before an overspend turns into a surprise at the end of the month.

My working days are spent in payment orchestration, and the habit from that world I’d carry over most directly is reconciliation. What a system says happened gets checked against a separate record of what did happen, routinely, and not only when something looks off. For agents paying in stablecoins, the separate record is the chain.

GetAgentCap, and what it assumes

GetAgentCap.com is a new service aimed at exactly that gap. It reads outbound USDC payments from public wallet addresses on Base and Solana, attributes each payment to the agent that made it in one combined view, and lets an operator set spending budgets per agent or per wallet, with an alert when one is exceeded. The question on its site states the problem more directly than I have: “You know what your agents are paying for. Do you know how much, and which one went over?”

What I find more interesting than any feature is what the service takes for granted. It doesn’t start from cards at all. It assumes the agents worth watching are paying in stablecoins from wallets on public chains, and that the missing piece is visibility over that spend, not permission to spend in the first place. That is the same bet I’d make about where agent payments are heading, and GetAgentCap is an early example of tooling built on it rather than waiting for the card networks to settle their standards.

It is also read-only. It never connects to a wallet and holds no private keys or seed phrases, so a tool whose job is watching spend can’t itself spend anything. The trade-off is that it can tell you a budget has been exceeded but can’t stop the payment that exceeded it: its budgets are alert thresholds, not limits enforced on the wallet. That puts it on a different layer from the spending limits on an agent card, which cap what the agent can do regardless of how it behaves. A control decides what an agent is allowed to spend, and a monitor tells you what it did spend, from a record the agent didn’t write. A serious setup wants both, whichever rail the money moves on.

Where this argument stops

The card networks aren’t going anywhere soon. They are accepted almost everywhere a person shops, and they are building for agents right now. A shopping agent buying from an ordinary online store will pay with whatever that store takes, and for a long while that will mostly be a card. My view on stablecoin rails is about direction, not about next year, and it’s a view rather than something I’d present to anyone as settled.

The visibility argument has limits too. GetAgentCap sees USDC on Base and Solana and nothing else, so the totals it shows are totals for that scope, not for everything an operation’s agents spend. If you run one wallet with a small number of payments, looking the wallet up directly gives you most of what you need. And if what you need is enforcement, meaning a payment that cannot happen once a limit is reached, monitoring doesn’t give you that. You need a control at the wallet or payment layer, with a record alongside it to check what the control let through.

If I were planning for agents that pay, I wouldn’t start by assuming the card is the default. I’d work out which rail the payments will actually move on, then decide where the independent record of that spend will live and who is going to read it. On a public chain, the first half of that is already taken care of.