Shared Payment Tokens, Virtual Cards, and IOU Tokens: What's the Difference?
There are now three distinct architectures for abstracting payment credentials away from AI agents: Stripe’s Shared Payment Tokens, virtual prepaid cards, and IOU tokens. The three agent payment models address different use cases and break down at different failure points. Understanding the differences — trust model, fraud exposure, minimum transaction size, revocation mechanics — matters more when you’re running agents at scale than when you’re running one agent in a demo.
The short answer
A Shared Payment Token is Stripe's credential primitive for agentic commerce: a scoped, time-bounded token that lets an AI agent initiate payment using a buyer's saved payment method without exposing the underlying card credentials. SPTs are observable, revocable per-token, and carry fraud signals through Stripe Radar. Launched December 2025 as part of Stripe's Agentic Commerce Suite.
SPTs are the newest of the three. Virtual cards have been used for agent payments since the early agent frameworks; IOU tokens emerged as a solution to the economics problems those virtual cards couldn’t solve. Each occupies a different layer of the payment stack.
What Are Shared Payment Tokens? (Stripe’s New Approach)
Shared Payment Tokens are Stripe’s answer to a specific problem: how does an AI agent pay a merchant using a customer’s payment method without the agent ever seeing the card number?
Stripe introduced SPTs in December 2025 as part of the Agentic Commerce Suite. The design: a buyer’s saved payment method (card on file with Stripe) is wrapped in a scoped token. The token is issued to an agent and is valid only for purchases from a specific seller, within a specific amount range, for a specific time window.
Three things SPTs do that plain card credentials don’t:
Credential isolation. The underlying card number is never exposed to the agent. The agent presents the SPT; Stripe resolves it to the underlying payment method. Compromise of the token doesn’t compromise the card.
Scope enforcement. The token is bound to a specific seller. An SPT issued for purchases at Merchant A cannot be used at Merchant B. This is enforced at the token level, not by instructing the agent to behave correctly.
Observable lifecycle. Stripe’s infrastructure tracks the token from issuance through use and expiry. Fraud signals (via Stripe Radar) are applied at the token level, not just at the card level.
SPTs are built on Stripe’s existing rails — Visa and Mastercard. That means card network minimums (~$0.30) and interchange fees (1.5–3.5%) still apply. SPTs solve the credential exposure problem but not the economics problem for high-frequency sub-dollar transactions.
According to Stripe’s 10 lessons from building agentic commerce: fraud rates for agentic commerce have been near zero in early deployments, in part because traditional fraud signals (browser fingerprints, mouse movements) don’t apply to agents — and SPTs provide cleaner fraud signal attribution because each token’s behavior is tracked individually.
How Virtual Cards Work for AI Agents — and Where They Break Down
Virtual cards are the oldest and most widely deployed approach to agent payments. A virtual prepaid Visa or Mastercard is loaded with a balance; the agent receives the card credentials (number, CVV, expiry) and uses them to make purchases anywhere cards are accepted.
The spending ceiling is the card balance — network-enforced. When the balance hits zero, the card declines. For relatively low-frequency agent purchases (SaaS subscriptions, cloud credits, one-off API purchases), this works cleanly.
The breakdown comes in two places:
Transaction economics. Card networks charge interchange fees on every transaction. On a $0.005 web search, the fee exceeds the transaction value. Virtual cards are economically impractical for sub-dollar transactions and completely unworkable for sub-cent ones. Why virtual cards fail at agent scale is a deeper breakdown of this problem.
Issuance overhead. The recommended security pattern for virtual cards is one card per task — issue, use, revoke. At low task frequency (10/day) this is manageable. At 1,000 tasks/day, the issuance, tracking, and revocation overhead becomes operationally significant. Card provisioning latency also adds per-task startup overhead.
Virtual cards also carry credential exposure risk that SPTs were specifically designed to address. The agent has the actual card number — if the agent’s context is compromised, the card number is compromised.
Where virtual cards remain the right tool: any purchase from a merchant who requires a real Visa or Mastercard number. SaaS subscriptions, cloud service credits, software licenses, online retail — none of these can accept IOU tokens or SPTs without custom integration.
IOU Tokens: The Internal Credit Model
IOU tokens bypass card networks entirely. Think of them like dollars held in a Starbucks wallet or eCredits with an airline: you pre-fund an account balance, and each tool call deducts from it at a published per-call rate. The balance is the ceiling. Sub-cent transactions are supported by design.
What an agent account contains when using the IOU model is different from a card-based model. There’s no card number, no network credential, no issuer relationship. The account holds a balance; the platform deducts per call; the balance depletes to zero and stops. The platform bears fraud liability within its ecosystem, which simplifies the developer’s compliance surface.
The economics case for IOU tokens is direct: a web search costs $0.003–0.005. Card interchange on that transaction would cost more than the transaction itself. An agent running 500 web searches per day on virtual cards would pay more in fees than in actual search costs. On IOU tokens, the economics are linear — you pay per call at published rates, no network overhead.
IOU tokens also consolidate billing. A single ATXP account covers web search, browsing, image generation, email, code execution, and commerce — no separate API keys or billing relationships per tool. For agents using 5–15 different tools, that consolidation reduces operational overhead significantly.
The limitation: IOU tokens don’t work at merchants who require a real card number. They operate within the issuing platform’s ecosystem. For third-party merchant purchases, virtual cards remain necessary.
Security and Trust Model Comparison
| Feature | Shared Payment Tokens | Virtual Cards | IOU Tokens |
|---|---|---|---|
| Backed by | Merchant relationship (Stripe) | Visa/Mastercard rails | Platform balance |
| Revocation | Per-token, instant | Per-card, instant | Per-account |
| Fraud liability | Card network | Card network | Platform |
| Crypto support | No | No | Yes (with ATXP) |
| Min transaction | ~$0.30 | ~$0.30 | Sub-cent |
| Works offline | No | No | Yes |
| Credential exposed to agent | No | Yes | No (balance only) |
| Network dependency | Stripe + card network | Card network | None |
| Fraud signal source | Stripe Radar + network | Network only | Platform |
| Multi-merchant | No (scoped to seller) | Yes (any card merchant) | No (platform ecosystem) |
The trust models differ in a meaningful way. Card-based approaches (SPTs and virtual cards) inherit card network trust infrastructure — chargeback rights, issuer fraud protections, network dispute resolution. This is well-understood and widely supported. IOU tokens trade that inherited trust for simpler economics and elimination of credential exposure — the platform is the trust layer, and the platform’s balance mechanics are the enforcement mechanism.
From a security standpoint, SPTs are strongest for merchant purchases because the underlying credential is never exposed. For tool-call infrastructure where the “merchant” is the agent’s own platform, IOU tokens eliminate the credential entirely — there’s nothing to expose.
The full protocol comparison covers how these models map to the broader protocol landscape (ACP, AP2, x402).
Which Approach Is Right for Your Agent?
Use Shared Payment Tokens when:
- Your agent is buying from Stripe-integrated merchants
- The buyer’s payment method is already on file with Stripe
- You need credential isolation without building a custom token system
- You’re within Stripe’s agentic commerce ecosystem
Use virtual cards when:
- The merchant requires a real Visa or Mastercard number
- Transaction frequency is moderate (under 200/day per agent)
- You can absorb interchange fees in your unit economics
- Merchant acceptance breadth matters more than transaction economics
Use IOU tokens when:
- Your agent makes hundreds or thousands of tool calls per day
- Transaction values are sub-dollar or sub-cent
- You want one balance covering multiple tool types
- You want a single audit trail across all tool calls
- You need crypto payment support
For most production agent stacks, the answer is more than one. IOU tokens for tool infrastructure (web search, image generation, email, code execution), virtual cards for merchant purchases that require a card number, and SPTs for Stripe-integrated merchant surfaces. ATXP is compatible with all three — IOU tokens natively, virtual cards via partner integration, and the same structural budget model applies across all three.
The underlying principle across all three approaches is the same: the agent should never have access to more payment capability than its current task requires. SPTs scope to seller. Virtual cards scope to balance. IOU tokens scope to pre-funded account. The scoping mechanism differs; the principle is identical.
FAQ
What are shared payment tokens for AI agents?
Stripe’s SPTs are scoped tokens that let agents initiate payments using a buyer’s saved payment method without exposing card credentials. Launched December 2025. Bound to specific sellers, time-limited, and observable throughout the transaction lifecycle via Stripe Radar.
How do virtual cards work for AI agent payments?
A virtual prepaid card gives the agent a real Visa or Mastercard number loaded with a balance. The card works anywhere cards are accepted. The balance is the hard ceiling. Card network minimums (~$0.30) and interchange fees (1.5–3.5%) apply to every transaction.
What is the difference between IOU tokens and virtual cards?
Virtual cards use card network rails with fees and ~$0.30 minimums. IOU tokens bypass card networks — pre-funded balance, sub-cent minimums, no per-transaction fees. IOU tokens work for high-frequency tool calls; virtual cards work for third-party merchants who require a card.
Which payment approach is best for AI agents?
Depends on the use case. SPTs for Stripe-integrated merchants. Virtual cards for any merchant accepting Visa or Mastercard. IOU tokens for high-frequency tool calls at sub-dollar values. Most production stacks use more than one.
Can AI agents use multiple payment approaches?
Yes. ATXP is compatible with all three — IOU tokens for tool infrastructure, virtual cards for third-party merchant purchases. The models are complementary, not mutually exclusive.
What is fraud liability for each approach?
SPTs and virtual cards: card network rules — issuing bank and network bear primary liability. IOU tokens: the platform (ATXP) handles dispute resolution within the ecosystem. For developers, IOU token fraud risk is simpler to reason about — there’s no card credential to steal.