Skip to content

SYSTEM Cited by 1 source

Stripe Issuing for agents

Stripe Issuing for agents is a Stripe product (launched 2026-04-29) that extends the existing Stripe Issuing API surface with primitives specifically for agentic spending — letting developers build custom agentic wallets, cards, and spending workflows on Stripe's card-issuance platform.

Docs: docs.stripe.com/issuing/agents.

It is the developer-facing primitive underneath Link's wallet for agents: Link's wallet for agents is Stripe's own consumer-product packaging of Issuing for agents, and third parties can build competing wallets or vertical-specific agentic spending products on the same primitive.

What Issuing for agents provides

Per the 2026-04-29 launch post, the product surface includes:

  • Single-use virtual cards — scoped, one-time-use card credentials that reject outside their scope (amount, currency, merchant). See concepts/single-use-virtual-card-for-agents.
  • Fund storage — agent-addressable balances the cards draw against; the infrastructure for funding flows distinct from raw-card-on-file.
  • Spending controls — programmable caps + policies at the card-issuance layer; permissions at the card level.
  • Transaction monitoring — historical + real-time visibility into card activity by agent, by merchant, by amount; observability the orchestrator / wallet operator surfaces to the end consumer or admin.
  • Advanced fraud tools — layered atop Radar; the agent-specific fraud surface (untrusted-agent heuristics, merchant-URL validation, context-field inspection) is an extension of standard Issuing fraud tooling.
  • Full Issuing API access — not a subset of Issuing; Issuing for agents "gives developers access to the full set of Issuing APIs to power agentic spending and custom financial workflows for agents and their users."

Four disclosed use-case shapes

The launch post enumerates four developer use cases the product supports:

  1. Developers automating their own business spend. Agents with programmatic purchasing authority within the developer's own organisation; recurring purchases, vendor payments. Agent = internal automation.
  2. Fintech providers embedding agent-issued cards for expense management. Reconciliation + real-time spend control for clients' employees / contractors. Agent = spend-policy-enforcing wrapper over corporate card.
  3. Vertical SaaS platforms issuing cards to SMB customers. Agent = automation bot under the platform's own brand (e.g. a property-management platform whose agent pays utility bills on landlords' behalf).
  4. Marketplaces issuing cards to sellers. Agent = seller-side bot automating supplier payments, logistics, and fulfillment purchases. Marketplace-branded seller-tooling.

The common shape across all four: a developer wants to extend agent autonomy to payments, the consumer / user doesn't need to build wallet infrastructure from scratch, and Stripe handles the card-issuance / fraud / reconciliation substrate.

                Stripe Issuing for agents
                (developer primitive — full APIs)
                 │
                 ├─ used by Stripe ─▶ Link's wallet for agents
                 │                    (consumer product for
                 │                     200M Link users)
                 │
                 ├─ used by fintech ─▶ expense-mgmt-agent
                 │                     (brand-customised)
                 │
                 ├─ used by SaaS  ───▶ vertical-agent-wrapper
                 │                     (under SaaS brand)
                 │
                 └─ used by marketplace ─▶ seller-agent
                                           (marketplace-brand)

Developers choosing Issuing for agents over Link's wallet for agents want:

  • Custom onboarding — not the consumer Link onboarding (e.g. KYB-gated, B2B-flavoured).
  • Custom fund flows — who funds the card, how / when authorization holds release, non-consumer settlement cadence.
  • Custom spending controls — spend policies that don't match Link's consumer per-transaction-approval default.
  • Custom agent permissions — granular per-card, per-merchant, per-amount constraints the wallet doesn't expose.
  • Custom fraud controls — plug in their own signals + heuristics alongside Stripe Radar at authorization time.
  • Agent-specific reporting — historical and real-time card-activity visibility shaped to the developer's operational model.

Developers choosing Link's wallet for agents over Issuing for agents directly want:

  • Access to Link's 200M-consumer membership base.
  • A no-wallet-to-build path to consumer-facing agents.
  • Stripe's pre-baked per-spend-approval UX.
  • Cross-payment-method abstraction (card + SPT + future stablecoins) without integrating each rail individually.

Architectural posture

  • Full-surface extension, not a subset. The product is full Issuing + agent-specific capabilities layered on top; developers aren't giving up Issuing primitives for Issuing for agents.
  • Composable with existing Stripe primitives — Radar for fraud; PaymentIntents for charges; Connect for platform flows. Issuing for agents doesn't replace any of these; it extends them with agent-specific surfaces.
  • Developer controls the consumer experience. Unlike Link's wallet for agents (Stripe-designed UX), Issuing for agents leaves the consent / approval / notification UX to the developer. This is the load-bearing trade-off: flexibility traded for building the UX yourself.
  • Card-network-backed by default. The primary credential is a Visa / Mastercard virtual card; agent cold-start on any existing merchant doesn't require the merchant to adopt a new payment rail. (Future rails — SPTs via ACP, stablecoins, agentic tokens — layer in additively.)

What's not disclosed

  • API schema — no spend-request API shape for the developer-facing primitive is shown in the launch post (only the link-cli wrapper over Link's wallet for agents). docs.stripe.com/issuing/agents is the pointer but not ingested here.
  • Pricing — Issuing is usually priced per card issued + per transaction + per fund-movement; agent-specific pricing unstated.
  • Authorization-time hook surface — can developers inject custom decision logic at authorization time (a la Issuing's existing authorization webhook)? Expected yes, unspecified in detail.
  • Cross-card aggregate spending controls — per-card controls are named but cross-card / per-agent / per-user aggregate caps are unstated.
  • Fund-flow primitives — top-up, earmarking, authorization-holds vs decoupled-settlement for agent cards specifically.

Seen in

Last updated · 446 distilled / 1,275 read