Skip to content

SYSTEM Cited by 1 source

Link's wallet for agents

Link's wallet for agents is a Stripe product (launched 2026-04-29) that lets a consumer-facing AI agent pay on the consumer's behalf using the cards and bank accounts already in that consumer's Link wallet — without the agent ever holding the raw credentials. Architecturally it is a wallet abstraction over credential issuance: the agent sees a wallet ("give me a scoped credential for this cart"), not a card number; behind the wallet Stripe mints a one-time-use virtual card or a Shared Payment Token (SPT) backed by the consumer's funding instruments in Link.

Product URL: link.com/agents. Built on Stripe Issuing for agents; distinct from (and in the consumer-agent tier of) that developer-facing primitive.

Primary flow (2026-04-29 launch)

consumer (already a Link user)
         │
         │  1. OAuth consent
         ▼
┌─────────────────┐         ┌──────────────────┐
│  agent          │  ── 2 ──▶│  Link wallet for │
│  (consumer's    │         │  agents          │
│   AI assistant) │◀── 5 ── │  (Stripe)        │
└─────────────────┘         └──────────────────┘
         ▲                            │
         │                            │  3. push spend-request
         │                            ▼
         │                  ┌──────────────────┐
         │                  │  consumer's Link │
         │                  │  app (web / iOS /│
         │                  │   Android)       │
         │                  └──────────────────┘
         │                            │
         │                            │  4. approve / reject
         │                            ▼
         │                  ┌──────────────────┐
         └── 6. settle ────▶│  Stripe PaymentIntents│
                            │  + Issuing           │
                            └──────────────────┘
  1. Consumer grants the agent access to their Link wallet via a standard OAuth flow. This is the once-per-agent handshake. See patterns/oauth-granted-access-to-user-wallet.
  2. Agent creates a spend request via the wallet API when it's ready to transact — worked example from the launch post: 
    link-cli spend-request create \
  --payment-method-id csmrpd_12345 \
  --merchant-name "Powdur" \
  --merchant-url "https://powdur.com" \
  --amount 3500 \
  --context "Purchasing the Powdur Glow Renewal Vitamin C
             Serum as a gift for $35." \
  --request-approval
  3. Wallet notifies the consumer (web, iOS, or Android Link app) with structured context: merchant, URL, amount, currency, and the agent's human-readable context.
  4. Consumer reviews and approves (or rejects) the request in the Link UI. Approval is required per spend at launch. See concepts/per-transaction-human-approval-for-agent-spend.
  5. On approval, the wallet mints and returns a scoped credential to the agent. Two credential shapes, abstracted behind the wallet API:
  6. One-time- use virtual card — for flows where a card charge is what the merchant accepts; scope-fields (amount, currency, merchant) bound on the card itself.
  7. SPT — for flows where the merchant is on ACP / agentic-commerce-native rails; scope-fields follow the ACP scoped-tokens RFC.
  8. Agent uses the credential to complete the transaction; Stripe settles against the consumer's Link-vaulted funding instrument and bills via the consumer's Link account.

The agent does not choose between card and SPT — the wallet picks. The abstraction is load-bearing: "Link handles the abstraction across payment options your agent might need — like cards and SPTs (with stablecoins and other payment methods coming soon)."

Architectural properties

  • Wallet-as-credential-issuer, not credential-holder. The agent doesn't hold a card. It holds an OAuth grant + the ability to request a spend. Each approved spend produces a fresh, scoped credential. See concepts/agent-wallet-over-raw-credential-issuance.
  • Per-transaction hard gate. Approval is required on every spend request; no credential is released pre- approval. This is a structural safety primitive, not a detection layer. Complements (rather than replaces) the per-credential scope-fields: even a leaked credential rejects outside its merchant / amount / currency scope.
  • Protocol-agnostic across payment methods. Today: cards + SPTs. "With stablecoins and other payment methods coming soon." Agent-side integration doesn't change as rails are added. Canonical instance of patterns/protocol-agnostic-commerce-layer at the payment-method altitude (the 2026-03-12 canonicalisation was at the commerce-protocol altitude).
  • Consumer-identity anchored by Link membership. The "200 million consumers" already in Link become the addressable surface for every developer building an agent on this product — a built-in mitigation for the agent-identity- resolution gap on the consumer side (the seller-side gap is separately addressed by Stripe's checkout products).
  • Built on Stripe Issuing, not a custom rail. The underlying primitive is Issuing for agents; Link's wallet for agents is Stripe's first-party consumer-grade packaging of Issuing for this use case. Third parties can build competing wallets on the same primitive.

Consumer-side capabilities

  • Approve / reject per spend. Default-on; required at launch.
  • Track agent spending. The Link UI shows historical agent-initiated transactions distinct from direct- consumer transactions.
  • Manage connected agents. Revoke an agent's OAuth grant entirely; fine-grained scope changes roadmap-implied.
  • Available surfaces. Web (link.com) + iOS + Android — launch spans all three.

Stated roadmap

  • Spending-limit controls. "We're planning on expanding these controls to let people set spending limits." Structural analogue of agent payment budget cap in Stripe Projects — but at the agentic-commerce altitude, not the agent-provisioning altitude.
  • Autonomy tiers. "Choose when agents can act without additional approval." Launch posture is "every spend needs approval"; the roadmap is conditional autonomy bounded by the set limits.
  • More payment methods. Stablecoins + other methods explicitly "coming soon"; the wallet abstraction keeps agent-side integration stable as these land.

What's not disclosed

  • OAuth scope schema — what scopes exist, what each permits, token TTL, refresh behavior.
  • Credential-type selection heuristic — when Stripe issues a one-time card vs an SPT behind the wallet API.
  • Approval-latency — typical notification-delivery + human-response time; SLA on approval-request-to-credential cycle.
  • Multi-agent-per-wallet model — can multiple agents hold concurrent OAuth grants? How is cross-agent observability handled?
  • Fraud / abuse heuristics — agent-spend-specific fraud tooling (LLM injection via context field, agent spoofing, merchant-URL poisoning defences).
  • Refund / dispute routing — who receives a chargeback notification, how it interacts with the consumer's Link account vs the agent vs the developer.
  • Pricing — Stripe fees for wallet-for-agents vs direct Issuing integration.
  • Settlement timing — when the consumer's Link-vaulted funding instrument is charged relative to approval and credential issuance (pre-auth, authorization-hold, decoupled-settlement not disclosed).

Distinction from sibling products

  • vs Issuing for agents — Issuing for agents is the developer primitive; Link's wallet for agents is the consumer product built on it. Use Issuing directly when building a custom wallet / first-party agent (fintech, vertical SaaS, marketplace brand-wrapped experience); use Link's wallet for agents when building a consumer-facing assistant that wants the Link-member fast-path.
  • vs Agentic Commerce Suite — Agentic Commerce Suite is seller-facing (catalog + checkout + fraud). Link's wallet for agents is consumer-facing (consent + credential issuance). The two compose: an agent using Link's wallet for agents can buy from a seller using the Agentic Commerce Suite, with Stripe translating between the two sides.
  • vs systems/stripe-projects — Stripe Projects is the orchestrator for agent-provisioning (long-lived cloud resources, subscription billing, monthly caps); Link's wallet for agents is for agentic commerce (one-off consumer purchases, per-transaction approval). Same company, complementary altitude, different primitives.

Seen in

Last updated · 446 distilled / 1,275 read