CONCEPT Cited by 1 source
Agent wallet over raw credential issuance¶
Definition¶
An agent wallet is an architectural abstraction in which an AI agent interacts with the user's payment system through a wallet endpoint — "issue me a scoped credential for this cart" — rather than through raw credentials (cards, bank accounts, API tokens). The wallet endpoint decides:
- What kind of credential to mint (single-use virtual card, SPT, future stablecoin, future agentic token, …).
- What scope fields to bind (amount, currency, merchant, time window).
- When to require additional consent (e.g. per- transaction human approval, future cap-based skips).
The agent never sees the user's underlying funding sources or their raw representation on a payment network.
Canonicalised by Stripe's 2026-04-29 launch of Link's wallet for agents: "Link handles the abstraction across payment options your agent might need — like cards and SPTs (with stablecoins and other payment methods coming soon)."
The wallet abstraction vs the raw-credential shape¶
── raw-credential shape (pre-2026) ────────────────────────
user ──▶ copies card data ──▶ agent
✗ agent holds PCI-scope credentials
✗ no scope enforcement at the credential
✗ single revocation = cancel the card, fan out to
every service charged
✗ scale-out to multiple agents = multiple copies of
the same card in multiple places
── wallet-over-credential-issuance (2026-04-29 Link) ──────
user ──▶ Link wallet (holds funding instruments)
│
│ per-spend:
│ ← spend-request (from agent)
│ ← human approval
│ → scoped credential (card or SPT)
▼
agent uses scoped credential once
✓ agent never touches the funding instrument
✓ scope enforced on the issued credential itself
✓ single revocation = revoke OAuth grant at wallet
✓ scale-out = many agents × many OAuth grants;
wallet is canonical source
Why a wallet abstraction (not just scoped credentials)¶
You can have scoped credentials without a wallet — e.g. a developer could integrate Issuing for agents directly and mint single-use cards on every spend. The wallet adds value on top of that primitive:
- Payment-method abstraction. The wallet picks the right credential type for the merchant — card if the merchant accepts cards, SPT if the merchant runs on ACP, stablecoin if future rails support it — without the agent integrating each rail.
- Consumer-anchored identity. The wallet has a consumer account; each user's funding instruments are aggregated there. Agents get a single access surface per user ("grant access to my wallet") rather than per funding-instrument ("grant access to my Chase card, grant access to my BofA account, …").
- Consent centralisation. The consent UI — approval screens, spending limits, autonomy tiers, connected- agent management — lives in one place. Without a wallet, these controls fragment across each rail each agent uses.
- Observability centralisation. Agent-spending history is visible from one surface (the wallet UI), not reconstructed across multiple card statements.
- Ecosystem portability. The agent integrates with a wallet API; moving from one wallet provider to another doesn't require changing the agent's payment-method integration.
Structural properties¶
- Agent-visible surface is issuance, not storage. The agent has no operation to read funding-source details — only to request a scoped credential.
- Each credential is fresh. No long-lived token shared between agent and wallet; each spend produces a new credential with the scope of the spend bound in.
- Wallet is the policy enforcement point. Human approval, spend caps, merchant allowlists, time windows, autonomy tiers — all enforced at credential-issuance time by the wallet, not distributed across the downstream payment rails.
- Revocation is wallet-grained. A compromised agent gets its OAuth grant revoked at the wallet; no need to rotate funding instruments.
- The wallet holds the funding sources; the agent holds temporary scoped credentials only.
Contrast with sibling agent-trust shapes¶
- Agent- provisioning uses a payment token backed by the orchestrator's payment method, but the credential is scoped to a provider + period (e.g. Cloudflare, one month). The wallet-over-credential-issuance shape is scoped to a merchant + amount + single transaction — much finer-grained because the transaction cadence is much higher.
- Machine payments bypass the wallet altogether and let the agent pay from its own budget via x402 / stablecoin rails. The wallet shape is about the user's money; machine payments are about the agent's operational budget.
Canonical instances¶
- systems/stripe-link-wallet-for-agents — launch-time canonical instance (2026-04-29) of the wallet-over- credential-issuance architecture. Abstracts cards + SPTs
- future stablecoins behind a single wallet API.
Prior art at other altitudes that shares the wallet shape but not the full substrate:
- Apple Pay / Google Pay / Samsung Pay — wallet abstractions for human buyers; credential shape is tokenised card (DPAN). Agent-usable surfaces are not standardised.
- PayPal / Venmo — wallet abstractions for human buyers; credential is account-balance-backed charge. Agent- usable surfaces exist but without per-spend scope enforcement.
The 2026-04-29 Link product is the first wiki instance of the wallet shape specifically designed around agent as the credential-requesting client with per-spend scope.
What's not disclosed¶
- Wallet-schema standardisation. Is Link's wallet for agents the only wallet, or does Stripe anticipate a W3C-style wallet spec? Launch framing is product- centric, not standards-centric.
- Multi-wallet-per-agent composition. Can an agent hold OAuth grants to multiple wallets (e.g. Link + Apple Pay + corporate wallet) and choose dynamically? The 2026-04-29 post is single-wallet-per-agent in framing.
- Wallet-to-wallet portability. Can a consumer move their connected-agents list + spending-history from Link to a competitor wallet?
Seen in¶
- sources/2026-04-29-stripe-giving-agents-the-ability-to-pay — canonical launch of the wallet-over-credential- issuance architecture for agents, with the two-shape credential abstraction (card + SPT) and stated roadmap for more payment methods.
Related¶
- concepts/single-use-virtual-card-for-agents — one of the two credential shapes the wallet mints.
- concepts/shared-payment-token — the other credential shape.
- concepts/payment-token-over-credit-card-sharing — generalised principle the wallet instantiates.
- concepts/per-transaction-human-approval-for-agent-spend — the consent gate the wallet enforces.
- concepts/agent-identity-resolution-gap — partially closed on the consumer side by wallet membership.
- systems/stripe-link-wallet-for-agents — canonical instance.
- systems/stripe-issuing-for-agents — developer primitive a wallet is built on.
- patterns/protocol-agnostic-commerce-layer — pattern this concept instantiates at the payment-method altitude.
- patterns/spend-request-approval-before-credential-issuance — composing pattern for the per-spend loop.
- companies/stripe — vendor.