How to Pause, Resume, and Close Agent-Managed SaaS Subscriptions
TL;DR
- The right architecture: one virtual card per subscription. Pause / resume / close becomes per-card operations, not per-subscription account dance.
- Pause: freeze the card (sub-second). Future merchant attempts decline; existing entitlements continue until billing cycle ends.
- Close: terminate the card + cancel the upstream merchant subscription via API. The card-side is instant; the merchant side depends on the merchant's cancellation flow.
When an autonomous agent manages your SaaS subscriptions — adding tools, removing them, swapping providers — you need precise control over each subscription's state. The architecture that scales: one virtual card per subscription. Then pause / resume / close are operations on the card, not on the subscription account.
Why one card per subscription?
Three benefits:
1. Surgical control. Pausing GitHub Copilot doesn't affect Linear. Each subscription has its own card; freezing one doesn't touch the others.
2. Cleaner ledger. Every charge tagged with the specific subscription. No "which Adobe subscription is this?" — the card identifies it.
3. Faster incident response. A SaaS vendor has a security breach. Freeze just their card. Other subscriptions keep working. Avoid platform-wide impact.
See [Virtual Cards for AI Agent Subscriptions](/blog/virtual-cards-ai-agent-subscriptions) for the full pattern rationale.
How does pause work?
Three states for a virtual card: active, frozen, terminated.
Pause = freeze the card. Sub-second from API call to network refusal. Implementation:
``bash
curl -X POST https://api.shatale.com/v1/cards/{card_id}/freeze \
-H "Authorization: Bearer $SHATALE_KEY"
`
What happens next:
- Any subsequent merchant authorization request is declined with reason card_frozen
. - Existing entitlements continue until the billing cycle ends (the merchant's side keeps you subscribed).
- The agent is alerted via webhook (card.frozen
event) so it knows to stop sending traffic.
Pause is reversible. Unfreeze is the same shape:
`bash
curl -X POST https://api.shatale.com/v1/cards/{card_id}/unfreeze \
-H "Authorization: Bearer $SHATALE_KEY"
`
How does resume work?
Unfreezing restores the card to active state. Next merchant authorization clears as normal.
If the merchant attempted charges while the card was frozen, they may have:
- Retried automatically (some merchants will).
- Suspended the subscription on their side.
- Sent you a dunning notification.
You may need to call the merchant's API or trigger their retry flow to restore service. The card side is one call; the merchant side depends on the merchant.
How does close work?
Two parts:
1. Terminate the card. Destructive. Card moves to terminated state. Cannot be re-activated. Implementation:
`bash
curl -X POST https://api.shatale.com/v1/cards/{card_id}/terminate \
-H "Authorization: Bearer $SHATALE_KEY"
`
2. Cancel the merchant subscription. Required separately because terminating the card just stops payment — the merchant doesn't auto-cancel the subscription. They'll continue to consider you subscribed (and bill the dead card, accumulating dunning).
Cancellation is merchant-specific. Three patterns:
- Merchant has a public cancellation API: easy.
- Merchant has only an admin UI: agent automation needed.
- Merchant has only email/support cancellation: human-in-the-loop.
Best practice: log the cancellation request and confirm via the merchant's billing webhook (subscription.canceled) before considering it complete.
What does the operating model look like?
A SaaS procurement agent typically has:
- Subscriptions table: rows for each active subscription, with card_id
,merchant,monthly_cost,status. - Pause/resume/close commands as agent tools. The agent can invoke them based on user requests or budget rules.
- Webhook handlers for: card.frozen
,card.terminated,subscription.canceled,payment.failed`. - Reconciliation logic that matches expected monthly charges to actual ones; flags drift.
What about subscription failure modes?
Three common ones:
1. Card frozen but merchant didn't notice. They keep charging the dead card. Their billing flags it; they send dunning. Either resume the card or finalize cancellation.
2. Merchant cancellation didn't take. You closed the card, but the merchant still considers you subscribed. They eventually flag the failed-charge and send dunning. Re-confirm cancellation through their channel.
3. Auto-renewal at higher rate. Merchant raises subscription price; agent's policy caps the new amount; charge declines. Either approve the new price or cancel cleanly. The agent should surface this for user decision.
What about subscription pricing changes?
Two policy strategies:
Strict: Card has a per-transaction cap matching the current price. Any increase declines. Forces explicit re-approval.
Permissive: Card has a per-transaction cap with headroom (e.g. 1.5x current price). Increases up to that ceiling auto-approved.
Strict is safer; permissive avoids interruptions. Pick based on subscription criticality.
FAQ
Can I pause a subscription mid-cycle and keep using it until cycle end?
Yes — that's exactly what freeze does. The merchant continues providing service through the cycle (because they have your prepayment). Subsequent charge attempts decline.
What if the merchant has annual billing?
Same flow. Freeze stops the next annual charge. The current annual entitlement runs to its expiration. Cancel ahead of the renewal window if you want to avoid the next year.
How do I track which subscriptions are paused vs canceled?
Card state (active/frozen/terminated) in your subscriptions table, synced via webhook. Plus the merchant's own subscription state if you can poll it.
What happens to refunds for canceled subscriptions?
Pro-rated refunds, if the merchant supports them, come through as a credit on the (now-terminated) card. The credit flows back to your funding account automatically — useful even though the card itself is dead.
Can the agent automatically pause low-usage subscriptions?
Yes. Common pattern: track usage via merchant API or your own analytics. If usage drops below a threshold for N cycles, agent freezes the card and surfaces a "consider cancellation" notification to the user.
Related reading
- [Virtual Cards for AI Agent Subscriptions: One Card Per Service](/blog/virtual-cards-ai-agent-subscriptions) — the foundational pattern
- [How AI Agents Use Virtual Cards for Autonomous Payments](/blog/how-ai-agents-use-virtual-cards) — issuing flow
- [How to Inspect Webhooks for Agent Payment Integrations](/blog/inspect-webhooks-agent-payments) — webhook handling for these events
External references
- [Visa Card-Not-Present subscription rules](https://developer.visa.com) — network rules around recurring billing
- [PSD2 SCA exemptions for recurring transactions](https://www.eba.europa.eu/) — relevant for EU subscription flows
---
By Ted L.. Last updated 2026-04-29.