Why Virtual Cards Aren't Enough for AI Agents
Virtual prepaid cards are the first thing most developers reach for when they want to give an AI agent spending power. Issue a card, load it with $50, hand the credentials to the agent. Problem solved.
It isn’t, though. It’s one problem solved — the merchant-purchase problem. There are four others the card doesn’t touch.
What virtual cards actually solve
A virtual prepaid card gives your agent a Visa or Mastercard number with a pre-loaded balance. The agent can spend up to that balance at any merchant that accepts the card. When the balance hits zero, the card declines.
That’s the complete value proposition. It’s a real value — universal merchant acceptance is something no other payment model provides today. If your agent needs to purchase a SaaS subscription, pay for cloud credits, or buy from an online retailer, a virtual card is the right tool.
The problem is the implicit assumption that payment = card. For agents, most spending isn’t at merchants. It’s at API endpoints.
The four things an agent needs to act in the world
An agent account is the full set of credentials and capabilities an AI agent needs to act independently in the world: a persistent identity (handle), spending capability (payments), a communication address (email), and access to tools (web search, image generation, code execution, file storage). A virtual card provides part of the payments layer only.
| Layer | What it provides | Virtual card covers this? |
|---|---|---|
| Identity | Persistent handle, recognized across services | ✗ |
| Payments | Spending capability for tools and merchants | Partial (merchant purchases only) |
| Communication | Email address for sending and receiving | ✗ |
| Tools | Web search, image gen, code execution, file storage | ✗ |
A virtual card covers the bottom-right corner of the second row. Everything else, the developer solves separately — or the agent simply can’t do it.
The sub-cent problem
Card networks charge interchange fees on every transaction: typically 1.5–3.5% plus a fixed per-transaction fee. On a $10 SaaS subscription, this is a rounding error. On a $0.005 web search query, the fee is 60–70% of the transaction value. On a $0.001 file storage operation, it exceeds the transaction entirely.
Most agent tool calls are sub-dollar. Many are sub-cent. The economics of card payments assume human-scale purchasing — occasional, significant transactions. They don’t assume 500 tool calls per hour.
The result: if you route agent tool calls through a virtual card, you’re paying card network overhead on every single one. At scale, you’re paying more in fees than in actual tool costs.
The IOU token model doesn’t have this problem. There’s no card network, no interchange fee, no per-transaction minimum. A $0.003 web search deducts $0.003 from the balance. Nothing more.
The per-card overhead problem
"The brightest nine-year-old on earth — really hard time opening a bank account."
Louis Amira, co-founder, Circuit & ChiselThe recommended pattern for virtual cards is one card per task — issue a card, complete the task, revoke the card. This limits blast radius: if something goes wrong, only that task’s card is exposed.
The pattern works at low frequency. At high frequency, it becomes its own engineering problem.
| Tasks per day | Cards issued | Cards revoked | API calls for card management |
|---|---|---|---|
| 10 | 10 | 10 | ~30 |
| 100 | 100 | 100 | ~300 |
| 1,000 | 1,000 | 1,000 | ~3,000 |
| 10,000 | 10,000 | 10,000 | ~30,000 |
At 1,000 tasks/day, card management generates 3,000 API calls per day that have nothing to do with the agent’s actual work. You’re building and maintaining a card lifecycle management system. That’s a separate engineering problem the virtual card model creates rather than solves.
With IOU tokens, there’s one balance. One API key. One audit trail. The overhead is constant regardless of task volume.
The identity gap
A virtual card has no memory of who spent it. Two agents using the same card type are indistinguishable. A merchant can’t build a relationship with a card number — it rotates, it expires, it changes.
Agent identity — a persistent handle that services can recognize across sessions — is a separate problem that virtual cards don’t address at all. When Louis describes agents as “economic actors,” the actor part requires persistence. A card number isn’t an actor; it’s a token.
If you want a merchant to recognize your agent, grant it standing permissions, or build any kind of ongoing relationship, the agent needs an identity that persists beyond a single transaction. That means an agent handle — not a card number.
Where virtual cards still belong
This isn’t an argument against virtual cards. It’s an argument against virtual cards as the complete solution.
Virtual cards are still the right tool for:
- Merchant purchases that require a real Visa number
- SaaS subscriptions and software licenses
- One-off purchases at retailers without custom API integration
- Any transaction where universal card acceptance matters
The practical pattern: IOU tokens for tool infrastructure (web search, image generation, email, code execution, file storage), virtual cards when the transaction requires a real card. Both, not one or the other.
# Tool calls: IOU tokens via ATXP
from atxp import AtxpToolkit
toolkit = AtxpToolkit.from_env()
search = toolkit.get_tool("web_search")
results = search.run("competitor pricing updates March 2026")
# Merchant purchase: virtual card (separate)
# card = issue_virtual_card(amount=50)
# checkout(card_credentials=card)npx atxpFree account. 10 starter IOU tokens. How IOU tokens work → · Virtual cards vs IOU tokens compared → · Full agent account →
Frequently asked questions
Why aren’t virtual cards enough for AI agents?
They cover one use case — merchant purchases — but not identity, sub-cent tool calls, high-frequency operations, or communication. The gap grows as agent complexity increases.
What’s the minimum transaction problem?
Card network fees (1.5–3.5%) exceed the value of sub-cent tool calls. Web searches at $0.003 each can’t route through a card economically.
What happens at high task volume?
Per-task card issuance creates 3,000+ card management API calls per day at 1,000 tasks/day. This overhead has nothing to do with the agent’s actual work.
What does an agent need beyond a card?
Identity (persistent handle), communication (email), and tools (web search, image gen, code execution, file storage). A virtual card provides spending at merchants. Full account model →
Should I stop using virtual cards?
No — use them for merchant purchases that require a real card number. Use IOU tokens for tool calls. Use both in the same agent stack.
What’s the alternative for tool calls?
IOU tokens. Pre-funded balance, per-call deduction, no card minimums. How it works →