What Kind of Payment System Do AI Agents Need?
The Real Question Is Not Whether an Agent Has a Wallet
As AI agents begin booking flights, buying software services, and hiring other agents to complete tasks, an obvious question emerges: how should they pay?
My first answer was simple. Traditional finance requires identity, accounts, and human confirmation, while crypto natively supports programmatic access, real-time settlement, and small transactions. The Agent Economy, I thought, would therefore have to run on crypto.
After looking more closely at the payment protocols now taking shape, I realized that this argument collapses two separate questions: who has the authority to spend, and how the money ultimately settles.
An agent is usually not the owner of the funds, nor does it need to become a separate legal person. It is better understood as a delegated operator: for a limited period, it may spend no more than a defined amount on behalf of a person or organization, and only with approved merchants.
The hard part is not giving an agent a wallet. It is making that delegation explicit.
An Agent Payment Has at Least Three Layers
The International Monetary Fund separates agentic payments into three layers: intent, authorization, and settlement. This is a more useful model than starting with “cards or crypto?”
| Layer | Question | Possible implementation |
|---|---|---|
| Intent | What does the user want to buy, and how much autonomy does the agent have? | Natural-language instructions, product and price constraints |
| Authorization | Who approved the transaction, and what are its limits, duration, and liability? | Signed mandates, payment tokens, human confirmation |
| Settlement | How does value ultimately move? | Cards, bank transfers, platform balances, stablecoins |
Large language models are probabilistic; payment execution has to be deterministic. A model can interpret “book me a suitable flight,” but it should not improvise how much to charge, who receives the funds, or whether the purchase is refundable.
The most important infrastructure for agent payments may not be a faster chain. It may be a mandate that software can verify.
Traditional Payments Are Still in the Race
Cards and bank accounts were not designed for autonomous software. Fixed fees, cross-border friction, and identity requirements make them particularly awkward for API calls worth only a few cents.
That does not mean an agent needs to open an account in its own name. Visa's Trusted Agent Protocol, Google's Agent Payments Protocol, and Stripe's Shared Payment Tokens all aim to let agents carry verifiable user authorization into existing payment networks. Instead of receiving a full card number, the agent receives credentials restricted by purpose, merchant, and amount.
This route has a clear advantage: merchant coverage, refunds, dispute resolution, and compliance systems already exist. For consumer purchases such as hotel bookings and physical goods, reusing those networks may be more practical than requiring every buyer to set up an on-chain wallet.
Some of the weaknesses of traditional payments can be addressed by a new protocol layer. Replacing the entire system is not the only option.
Where Crypto Really Does Have an Advantage
Crypto still fits some agent-payment scenarios very well. Its advantages simply do not cover every scenario.
Coinbase's x402 protocol places payment requirements directly inside HTTP requests and responses. When an agent calls a paid API, it can discover the price, pay in stablecoins, and continue the request in software—without first creating an account, buying a subscription, or waiting for manual approval. That is compelling for small, frequent machine-to-machine transactions.
Stablecoins also make round-the-clock, programmable, cross-border settlement possible. But “on-chain” does not automatically mean cheap, safe, or universally accessible. Network fees, custody, private-key management, depegging, privacy, and jurisdiction-specific regulation all remain real concerns.
A more practical comparison looks like this:
| Settlement method | Best suited to | Main trade-off |
|---|---|---|
| Tokenized card or bank payment | Consumer purchases, refunds, and disputes | Micropayments and cross-border transactions still create friction |
| Stablecoin or on-chain payment | API micropayments and round-the-clock machine settlement | Custody, compliance, privacy, and on-chain risk |
| Internal platform balance | Frequent transactions within one marketplace | A closed ecosystem with weak cross-platform portability |
Stripe's Machine Payments Protocol supports both stablecoins and shared payment tokens. That points toward a future in which protocols standardize intent and authorization while several settlement rails compete underneath.
Constraints Matter More Than Speed
If an agent is going to spend money for me, these are the questions I care about:
- How much can it spend, and when does its authority expire?
- Which categories can it buy from, and may it pay a new merchant?
- What amount requires fresh confirmation?
- Does every transaction leave a verifiable order, authorization, and execution record?
- Can I revoke access at any time, and who handles refunds and liability when something goes wrong?
- Once the model proposes a transaction, can deterministic software validate and execute it?
These constraints apply to cards, stablecoins, and platform balances alike. Without them, faster settlement merely makes mistakes happen faster.
My View Now
I still expect crypto to become an important part of the Agent Economy, especially for accountless machine services, API micropayments, and cross-border settlement. But it is not the only answer, and it cannot replace authorization, liability, or risk controls.
Future agents may use both card tokens and stablecoins, just as software today uses databases, cloud services, and third-party APIs together. Users do not need to care which rail carries every transaction. They need to know the limits within which an agent can act for them.
The real challenge, then, is not “how can AI own money?” It is this: how can an uncertain machine use human money within authority that is deterministic, limited, and accountable?