Skip to content

CONCEPT Cited by 1 source

Single-use virtual card for agents

Definition

A single-use virtual card for agents is a payment credential issued by a wallet / issuer to an AI agent for one authorised transaction only, carrying scope-fields (amount, currency, merchant) that the card network rejects against if the agent tries to use the card outside that scope. After the single authorised transaction (or scope violation), the credential is dead.

Canonicalised by Stripe's 2026-04-29 launch of Link's wallet for agents and its underlying Issuing for agents product, where it is one of two credential types the wallet mints in response to an approved spend request (the other being a Shared Payment Token).

The 2026-04-29 launch post describes it as: "You can now give agents programmatic access to Link and the ability to get a one-time-use card or a Shared Payment Token (SPT), backed by the cards and bank accounts already in your wallet."

Architectural shape

              ┌────────────────────────────────┐
              │   user's funding instruments   │
              │   (vaulted at issuer — card,   │
              │    bank acct)                  │
              └────────────────────────────────┘
                              │
                              │ backs
                              ▼
┌────────────┐  spend    ┌───────────────┐  scoped  ┌─────────┐
│  agent     │  request  │   wallet /    │  card    │  agent  │
│            │ ─────────▶│   issuer      │ ────────▶│         │
│            │           └───────────────┘          └─────────┘
│            │                                            │
│            │                                            │ used
│            │                                            ▼
│            │                                      ┌─────────┐
│            │                                      │ merchant│
│            │                                      │  auth   │
│            │                                      └─────────┘
│            │                                            │
│            │           enforces scope on auth:          │
│            │           - amount ≤ issued-cap            │
│            │           - currency = issued-currency     │
│            │           - merchant = issued-merchant     │
│            │              else: REJECT                  │
└────────────┘                                            │
                                                          ▼
                                                    ┌─────────┐
                                                    │ settled │
                                                    │         │
                                                    └─────────┘

Distinguishing properties

  1. Single-use. The card is burned after its single authorised transaction (or scope violation). It does not retain re-use value.
  2. Scoped at the credential layer. Unlike a general- purpose card with CVV + expiry, the credential itself encodes the transaction it's allowed to complete. Merchant-boundary enforcement at the card network rejects anything outside scope.
  3. Backed by a vaulted funding source. The single-use card is not itself the user's money; it authorises against a funding instrument (card, bank account) held inside the issuer's vault. The agent never sees that funding instrument.
  4. Card-network-backed settlement. Once authorised, the charge settles through normal card-network rails (Visa / Mastercard). The merchant's integration doesn't change — it accepts a card like any other.
  5. Indistinguishable from an ordinary card at the merchant boundary — until scope is violated. The merchant sees a card charge; the scope-check is issuer-side, invisible to the merchant.

Distinction from Shared Payment Token (SPT)

Property Single-use virtual card Shared Payment Token (SPT)
Rails Card network ACP / agentic-commerce
Scope enforcement At card-network auth At ACP seller-backed handler
Merchant integration change None (card is a card) Merchant must speak ACP
Buyer-authentication carried No Yes (built-in per ACP 2026-03)
Fraud surface Card-network fraud tooling SPT-metadata + Stripe-network-density
Re-use Single transaction Single cart / intent
Disclosure to merchant Full card data Token + scoped metadata

Both credentials deliver the same architectural payoff — the agent doesn't hold the user's vaulted funding source — but they target structurally different merchant surfaces. Link's wallet for agents abstracts the choice behind a single spend-request API, per concepts/agent-wallet-over-raw-credential-issuance: the agent asks for a scoped credential; the wallet chooses which shape depending on the merchant.

Why single-use

Two compounding reasons:

  1. Leaked-credential blast radius goes to zero after first use. A general-purpose card in an agent's memory is a standing liability — every log line, every prompt- injection payload, every crashed process risks exfiltration. A single-use card is worthless once the authorised transaction completes.
  2. Scope enforcement needs a per-transaction scope. A reusable card with "spend up to $500" can't express "spend up to $35 at Powdur and then stop." Re-issuing a fresh single-use card for each transaction makes the per-transaction scope representable inside the credential.

The combination is load-bearing for the agent-payment shape: without single-use + scoping, the best the ecosystem can do is post-hoc fraud detection + chargeback; with it, abuse caps structurally at the issued scope.

Implementation rail (2026-04-29)

Composable with

  • Refund / chargeback flows. Standard card-network dispute mechanics apply — the card's single-use nature doesn't change refund availability.
  • Merchant loyalty. Because the card presents at the merchant as an ordinary card, the merchant can continue to apply loyalty / reward programs to it (though attribution to the actual consumer requires separate identity resolution; see concepts/agent-identity-resolution-gap).

What's not disclosed

  • TTL — how long an issued single-use card lives before auto-expiring if unused. Likely a short window (hours / days) but not specified.
  • Re-issuance policy on failed auth — if the merchant rejects the card for reasons unrelated to scope (e.g. merchant outage), is the card still burned, or can the agent retry?
  • Cross-currency conversion — if scope names USD and the merchant charges in EUR, how is the scope-check resolved? Card-network rails do currency conversion at settlement but the scope-check precedes settlement.
  • Partial-use semantics — can a single-use card cover multiple charges from the same merchant summing ≤ cap (e.g. a cart that splits into shipment + gift-wrap)? Or strictly one authorisation?

Seen in

Last updated · 446 distilled / 1,275 read