How AI Agents Use Virtual Cards for Autonomous Payments

TL;DR

• AI agents transact via virtual cards issued per-agent (sometimes per-subscription or per-task), not by sharing a corporate card or a credential.
• Each transaction routes through a policy engine that evaluates spending rules in under 100ms before authorization is granted.
• Approved transactions execute on the network and reconcile to a per-agent ledger; declines return a reason code and explanation.

AI agents make payments by holding a programmatic virtual card linked to a delegation, not by storing a credit card credential. Every transaction the agent attempts is evaluated against a spending policy in real time, settled against a per-agent ledger, and surfaced with a reason code if declined. Here's the full lifecycle.

How does the issuing → auth → settlement flow actually work?

Five stages. End-to-end:

1. Publisher creates an agent with a spending policy. The agent gets a unique agent_id tied to a policy_id (and, in production, to a delegation from an end user).
2. A virtual card is issued to the agent. In production, the card returns as a tokenized handle — not a raw PAN. The card is single-use, merchant-locked, or open-loop depending on use case.
3. The agent uses the card online. It enters the card details (or hands a handle to a checkout SDK) at a merchant. The merchant submits an authorization request through their acquirer to the network.
4. The network routes the auth to Shatale. Our policy engine evaluates 15+ rule types in <100ms — amount limits, MCC restrictions, geo, time windows, velocity, custom approval thresholds.
5. Approved transactions execute and settle. A ledger hold is created during auth; settlement clears the hold and produces a debit/credit pair tagged with agent_id, merchant, and policy_version. Declined transactions return a reason code that the agent can act on.

What kinds of virtual cards do agents use?

Three common shapes:

• Single-use cards. Issued for one transaction, voided after. Maximum control; minimum reusability. Good for one-off purchases by an agent that may not transact again.
• Merchant-locked cards. Bound to one merchant ID. Used for ongoing relationships with a specific vendor — e.g. a SaaS subscription handled by an agent that should never pay anyone else.
• Open-loop cards with policy. Reusable across merchants, but every charge runs through the policy engine. Good for general-purpose agents (travel agents, procurement agents) where the merchant set is broad but the rules are tight.

The choice depends on the agent's purpose. See Virtual Cards for AI Agent Subscriptions for the per-subscription pattern in detail.

What does the agent actually "hold"?

Not a card credential. The agent holds:

• A reference to the card (a token or handle).
• A delegation token that proves it's authorized to spend on that card.
• The policy version it's operating under (so audit logs are reproducible).

The PAN, CVV, and expiry never leave the platform. When the agent checks out at a merchant, the platform's checkout SDK or API resolves the handle to a tokenized PAN at transaction time. Card data stays vaulted; the agent gets capabilities, not credentials.

How does the policy engine know what to allow?

When a publisher creates the agent, they attach a policy. The policy is a configurable rule set. Examples:

• TravelBot policy: max $5,000 per transaction, MCCs 3000-3299 + 7011 + 4511 only, geo allow {US, CA, GB, FR, DE}, no business-hours restriction.
• SaaS procurement bot: max $500 per transaction, software MCCs only, $2,000 weekly cap.
• Locked-down research assistant: max $50 per transaction, paywall publisher MCCs only, business hours, weekday only.

Policies are versioned and immutable. A transaction in flight evaluates against the snapshot it was issued under. Mid-flight policy changes don't break in-flight charges.

What happens when a transaction is declined?

The agent gets two things:

• A machine-readable reason code (e.g. mcc_blocked, velocity_exceeded, geo_denied).
• A human-readable explanation (e.g. "Merchant category 7995 (gambling) is blocked by policy 'TravelBot v1'.")

Both go into the agent's audit log. The agent (or the publisher's app) can decide whether to fall back, ask for human approval, or surface the decline to the end user.

Where does this break the legacy stack?

Three places where a regular Stripe / Adyen / corporate-card setup hits walls:

• Identity. Cards assume a cardholder. Agents need delegation, not credentials.
• Velocity. Human velocity rules misfire when an agent batches 50 calls in parallel. Agent-aware fraud (forthcoming) models behavior, not just rate.
• Reconciliation. Settling thousands of transactions back to specific agents requires per-agent ledger entries from auth onward — not after-the-fact tagging.

See Why AI Agents Need Their Own Payment Infrastructure for the full breakdown.

What use cases run on this infrastructure?

Live in production as of April 2026:

• Travel agents booking flights and hotels within budget.
• SaaS procurement agents managing software subscriptions and renewals.
• Shopping assistants purchasing from online stores within a category whitelist.
• Research agents buying access to paywalled content per query.
• Workflow automation agents paying per-call MCP server fees.

FAQ

Does the agent see the actual card number?

No. In production, the agent gets a tokenized handle. The platform's checkout SDK resolves the token at transaction time. PAN/CVV/expiry stay vaulted. (Sandbox returns raw values for development convenience.)

What happens if the policy gets updated mid-transaction?

The transaction evaluates against the policy version that was active when the auth request landed. New policy versions apply to the next transaction. This makes audit logs reproducible and avoids mid-flight race conditions.

Can an agent have more than one virtual card?

Yes. A common pattern is one card per subscription — one for the SaaS agent's GitHub Copilot, one for its Linear, one for its Slack — so each can be paused, swapped, or canceled independently. See Virtual Cards for AI Agent Subscriptions.

How fast can a card be frozen if the agent misbehaves?

Sub-second from API call to network refusal. The card is moved to a frozen state in our system and the next auth request gets declined with reason code card_frozen. There's also an emergency-stop flag at the policy level that disables all cards under the agent in one call.

What's the difference between this and just issuing employee corporate cards programmatically?

Corporate cards assume one card, one human cardholder who passed KYC. Agents need many cards, no human cardholder, delegation chains, and per-agent ledgers. See Why Corporate Cards Don't Work for Autonomous Agents.

Related reading

• Why AI Agents Need Their Own Payment Infrastructure — the category-level argument
• How We Built a 100ms Policy Engine for AI Agent Transactions — the engine that evaluates these auths
• Get Your First Agent Payment in 5 Minutes — hands-on quickstart

External references

• EMVCo 3D Secure 2.x specification — authentication for high-risk authorizations
• PCI DSS v4.0 — applies to virtual card data handling
• Visa Token Service — tokenization framework underlying the handle abstraction

---

By Vlad K. Last updated 2026-04-29.