An AI shopping agent that buys from your store increasingly does not pay the way its owner would. On April 29, 2026, Stripe launched Issuing for agents — the infrastructure to give an agent “its own virtual card with per-agent spend limits, merchant category controls, and custom authorization rules” — plus Link’s wallet for agents, which lets a consumer’s own Stripe Link wallet hand an agent a one-time-use card or a Shared Payment Token scoped to “amount, currency, and merchant,” without ever exposing the underlying card number (Stripe blog, Apr 29, 2026). This is now a documented, general-availability API, not a prototype — and almost nobody has written down what it does to the merchant’s side of the transaction.

The short version: checkouts, fraud scoring and capture logic were tuned for human cards that carry history and headroom. Agent-issued cards have neither, by design.

The card the agent shows up with

Stripe’s own developer example shows exactly what an agent card looks like: a virtual card created with lifecycle_controls[cancel_after][payment_count]=1 and a spending_controls[spending_limits] entry capped at a fixed amount “per_authorization” — the card cancels itself the moment one charge clears (Issuing for agents docs). Stripe’s Issuing product describes single-use cards plainly: “Issue virtual cards scoped to a single task or session. Cards are automatically invalidated after use.” Every purchase attempt also triggers a real-time authorization webhook the card issuer can approve or decline before the charge completes.

The design goal is the buyer’s safety — a misbehaving agent can only burn the exact amount its card was minted with. But that same safety property is a signal most fraud stacks were trained to distrust.

Failure mode 1: your fraud scoring flags the good money

A card with no transaction history and an authorization for a suspiciously exact amount reads as fraud in many rule sets — and in 2026 it is also the ordinary shape of a legitimate agent purchase. That’s inference from how the cards are built, not a retrieved fraud-loss statistic: a rule tuned on years of human-card behavior has no precedent for a card designed to be used exactly once. If your store verifies agent identity at the edge (see Web Bot Auth and agentic checkout), you at least know a verified agent reached checkout — the payment layer still makes its own, separate call.

Failure mode 2: the exact-amount cap meets your capture logic

Many checkouts authorize first and capture later, sometimes for more than the original authorization once shipping or tax is finalized. Stripe’s own capture documentation is explicit about the default: a capture can be for less than the authorized amount, and capturing more requires overcapture-eligibility (“If attempting to capture more than the initial amount… refer to the overcapture documentation”) — and once you partially capture a payment, “you can’t perform another capture for the difference” (Place a hold on a payment method). An agent card minted at the exact cart total has no such headroom at all: Stripe’s Issuing controls page notes an “unconfigurable default spending limit” applies to every authorization on top of whatever per-authorization cap the issuer set (Issuing spending controls). Push a capture past that ceiling — a tax recalculation, a substituted item — and it fails against the card, not against your Stripe account’s general capture rules.

Failure mode 3: single-use cards break everything card-on-file

Subscriptions, split shipments, and retries on a bounced capture all assume a stored card still exists when the second charge runs. A card built to “automatically invalidate after use” does not survive that by design. If agents become a real share of orders, “save card for later” needs an agent-aware branch, or at minimum monitoring for how often a deferred capture dies against an already-cancelled card.

What to check

  • Ask your PSP how single-use, first-authorization virtual cards score under your current fraud rules today, and whether verified-agent signals can feed that scoring instead of penalizing it.
  • Audit every place your capture amount can exceed your authorization (shipping recalculation, tax, substitutions) and what happens when that capture fails against a card with zero headroom.
  • Inventory deferred-charge flows (subscriptions, split shipments, retries) and decide what they should do when the stored card was single-use.
  • Segment failed payments by card type if you can — otherwise this failure mode is invisible in your own analytics.

FAQ

Are AI agents really paying with single-use virtual cards today?

Yes. Stripe’s Issuing for agents and Link’s wallet for agents shipped April 29, 2026, and issue one-time-use cards or Shared Payment Tokens that cancel after a single authorization clears, scoped to a specific amount, currency and merchant.

Doesn’t Visa’s Trusted Agent Protocol solve this?

No — TAP addresses identity, letting a merchant know a transaction was initiated by a registered agent. It does not change how your fraud rules score a single-use card, how your capture logic handles a zero-headroom authorization, or what happens to card-on-file flows when the card is already cancelled. See the two rails of agentic checkout.

Can I just block agent purchases instead?

You can, but single-use agent cards are not distinguishable from ordinary virtual cards in most checkout flows, and the person behind the agent is still your customer, delegating the purchase. Blocking the payment profile blocks a growing slice of legitimate demand.

Sources

AgentReady at agentready.market, operated by Boxing Vision, unaffiliated with other AgentReady-named products.

A payment that fails silently after checkout is exactly the kind of transaction-layer failure a discovery-focused audit never sees — it’s the gap AgentReady scores instead.