Virtual Cards for AI Agent Subscriptions: One Card Per Service
TL;DR
- Issue one virtual card per SaaS subscription, not one card for all of them. Each card is merchant-locked, has a per-transaction cap matching the subscription price, and can be paused/canceled independently.
- The cost (a few extra cards) is trivial. The benefits (surgical control, clean ledger, faster incident response) compound across the agent's portfolio.
- This pattern works for any agent managing recurring spend. SaaS procurement, ad spend, content APIs, any subscription-driven cost.
When an AI agent manages multiple SaaS subscriptions, the architecture choice that simplifies everything is one virtual card per subscription. Cancel one without affecting others. Spot anomalies on the per-card ledger. Freeze one card during a security incident without breaking the agent's other operations.
Why one card per subscription?
Surgical control. Want to cancel GitHub Copilot? Freeze its card. Linear keeps working. The other 12 subscriptions keep working.
Clean ledger. Every transaction tagged with the specific subscription via the card. No "which Adobe subscription was this?", the card answers.
Faster incident response. A SaaS vendor gets breached. Freeze their card alone. Other subscriptions unaffected. No platform-wide stop-payment.
Per-subscription policy. Each card carries its own policy, per-transaction cap matching the subscription price, merchant-locked, geo-locked, currency-locked. Tighter control than a shared card.
Easier reconciliation. Monthly close: each card's transactions equal the subscription's price (modulo prorated changes). Drift is immediately visible.
What about the card-management overhead?
A typical agent might manage 20-50 subscriptions. That's 20-50 virtual cards. Sounds like a lot. In practice, it isn't:
- Cards are programmatic; issuance is a single API call.
- Card lifecycle (freeze, unfreeze, terminate) is also programmatic.
- The dashboard shows all cards in one view, filterable by status.
- Most issuers don't charge per-card fees at this scale.
Manageability of 20 cards via API > manageability of 1 card with 20 manual exception handlings.
How does the per-card policy work?
Each card has a policy attached. A typical SaaS subscription card is locked to a single merchant, say, GitHub, capped per transaction and per month (with slight headroom for tax/proration), and restricted to the expected currency and country.
Any deviation: declined at auth.
What about subscription price increases?
Two patterns:
Strict per-card cap. When the merchant raises the price, charge declines. Forces user re-approval.
Headroom per-card cap. Cap is set 25-50% above current price. Auto-accommodates small increases. Hard cap on large jumps.
Strict is safer; headroom avoids interruptions for small price changes. Choose per subscription criticality.
What does the agent's subscription portfolio look like in practice?
A SaaS procurement agent might have:
| Subscription | Card | Cap/month | State |
|--------------|------|-----------|-------|
| GitHub Copilot | crd_001 | $22 | active |
| Linear | crd_002 | $14 | active |
| Slack | crd_003 | $250 | active |
| Notion | crd_004 | $30 | paused |
| Vercel | crd_005 | $80 | active |
| ... | ... | ... | ... |
When the user wants to pause Notion, the agent freezes crd_004. When they want to cancel it, terminate crd_004 + call Notion's cancellation API.
How does this compare to using one shared card?
| | One card per subscription | One shared card |
|--|---------------------------|------------------|
| Cancel one subscription | Freeze one card | Update merchant blocklist |
| Subscription anomaly | Freeze one card | Halt all subscriptions |
| Monthly reconciliation | Per-card matches subscription price | Aggregate; drift detection harder |
| Incident response | Surgical | Platform-wide |
| Operational simplicity | Slight overhead managing cards | Slight overhead managing exceptions |
The "managing cards" overhead is one-time setup. The "managing exceptions" overhead recurs forever. Per-subscription cards win at meaningful subscription counts.
How do you handle one-off charges from a subscription merchant?
A merchant might bill non-subscription items occasionally, overage charges, add-on services, one-time fees. Two approaches:
Option 2 is cleaner; option 1 is faster.
What happens if the merchant changes their billing flow?
E.g. they go from monthly to annual. The merchant attempts a $240 charge instead of $20. The strict per-transaction cap declines. User gets notified, can approve the change, agent updates the card's cap.
This is a feature, not a bug. The decline forces a decision instead of silent compliance.
FAQ
Doesn't this mean I have a card list that grows over time?
Active cards stay limited to active subscriptions. Terminated cards are archived but not deleted (audit trail). Most production agents have 20-100 active cards.
Can I issue cards in bulk?
Yes, bulk endpoint accepts an array of card-creation requests with policies. Useful for migrating an existing subscription portfolio.
What about subscriptions with multiple billing models (annual + monthly + usage)?
Multiple cards if the policies differ significantly. One card if the cap can encompass all variants.
How do I prevent the agent from spinning up new cards beyond what I want?
Policy at the agent level: max active cards. Or require human approval for new card issuance. Both supported.
What if my subscription needs vary by region (different price in EU vs US)?
Issue separate cards per region with the right currency_allow and geo_allow. Same SaaS subscription, different cards depending on which user / which region.
Related reading
- [Merchant Whitelisting for AI Agents](/blog/merchant-whitelisting-ai-agents), locking a card to a single merchant
External references
- [Visa Card-Not-Present rules for recurring](https://developer.visa.com), network rules
- [PSD2 SCA recurring transaction exemptions](https://www.eba.europa.eu/). EU regulatory framework
---
By Ted L.. Last updated 2026-04-29.