# hill-stripe-link-wallet-agents-issuing-2026-04-29

## Veille

Product announcement published on the **Stripe** blog on **April 29, 2026** by **Dan Hill** (Product Manager, Link Consumer Product), following on from the **Stripe Sessions 2026** keynote: the launch of **Link's wallet for agents**, built on a new building block, **Issuing for agents**. **The diagnosis fits in one sentence, and it is the most important one in the text**: *"While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today."* → **Stripe acknowledges that machine-native payment protocols are not ready, and delivers a workaround for existing rails rather than a bet on new ones.** **The mechanism**: a consumer grants an agent access to their Link wallet via a **standard OAuth flow**; the agent then issues a *spend request* and receives either a **single-use card**, or a **Shared Payment Token** — backed by the cards and bank accounts already present in the wallet. Cardinal point: *"The agent never gets access to your raw payment credentials."* The credential is **scoped** (amount, currency, merchant) and the agent must supply the **transaction context** so the human understands what they are approving — the example given in the CLI is explicit: `amount 3500`, `merchant-name "Powdur"`, `context "Purchasing the Powdur Glow Renewal Vitamin C Serum as a gift for $35."`. **The structuring constraint is temporal, and it is owned as such**: *"Today, each request requires the person's review before the credential is shared with your agent"* — **human** approval, **transaction by transaction**, on the web or in the **new Link iOS and Android apps**. Spending limits and cases where the agent would act **without additional approval** are announced, not delivered. **The second layer is the real infrastructure product**: **Issuing for agents** opens the full set of Issuing APIs to anyone building their own agentic wallet — single-use virtual cards, fund storage, spend controls, card-level permissions, **at-authorization** antifraud controls, real-time visibility. Four use cases are cited: internal spend automation, agentic cards embedded at **fintechs**, **vertical SaaS** platforms issuing cards to SMBs under their own brand, **marketplaces** whose selling agents pay suppliers and logistics. **Distribution argument**: Link claims **more than 200 million consumers**, and the article cites **OpenClaw** as an example of a personal agent that benefits. **Two reservations worth flagging up front**: per-transaction approval is presented as a design convenience when it is actually **an admission that delegated agent authorization is not solved**; and stablecoin, *agentic tokens*, and "other payment methods" are all in the **future tense** (*"coming soon"*).

## Titre Article

Giving agents the ability to pay

## Date

2026-04-29

## URL

https://stripe.com/blog/giving-agents-the-ability-to-pay

## Keywords

Stripe, Link, wallet for agents, Issuing for agents, agentic commerce, single-use card, virtual card, Shared Payment Token, payment credential, scoped credential, spend request, expense request, human approval, per-transaction review, transaction context, OAuth, payment delegation, spending cap, spend control, card-level permissions, at-authorization antifraud control, transaction monitoring, card rails, machine-native payment protocol, Agentic Commerce Protocol, stablecoin, agentic token, Link iOS, Link Android, 200 million consumers, OpenClaw, personal agent, shopping agent, fintech, vertical SaaS, marketplace, expense management, programmatic spend, recurring purchase, Stripe Sessions 2026, Dan Hill, AI economic infrastructure

## Authors

**Dan Hill** — Product Manager, **Link Consumer Product** chez Stripe. Auteur de l'annonce sur le blog Stripe, rubrique *Product*. Le rattachement au produit *Link Consumer* est significatif : l'annonce est écrite depuis le **portefeuille grand public**, pas depuis l'équipe protocole ni depuis Issuing — ce qui explique que le consentement de l'utilisateur final structure tout le texte.

**Stripe** — position singulière dans le paysage du commerce agentique : co-auteur avec **OpenAI** de l'**Agentic Commerce Protocol** (29 septembre 2025), et simultanément **émetteur** (Issuing) et **portefeuille** (Link). L'entreprise n'est donc pas seulement un participant au débat sur les protocoles : elle détient les rails que ces protocoles prétendent remplacer. L'annonce est explicitement rattachée à la keynote **Stripe Sessions 2026**.

## Ton

**Profile**: **payments-infrastructure product announcement**, sober and operational register, without forward-looking emphasis. Short format, canonical for the Stripe blog: context → launch → "how it works" in three illustrated steps → underlying building block → use cases → call to the documentation.

**Style**: the **demonstration proceeds by walking through a transaction**, not by argument. Stripe sets up a concrete scenario (a shopping agent recommending clothing), then walks through the three steps — OAuth, *spend request*, approval — with two screenshots and **a CLI excerpt**. The code is the argument here: seeing `link-cli spend-request create` with its `merchant-name`, `amount`, `context`, `request-approval` parameters says more than any architectural promise. **A command that exists is shown, rather than a diagram that will exist.**

**Most notable trait: the candor about protocols.** *"While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today."* Coming from the **co-author of the Agentic Commerce Protocol**, the sentence is remarkably frank — Stripe publicly notes that the standard it promotes does not yet have the necessary traction, and delivers the workaround. **This is not a contradiction, it is a risk hedge.**

**Security is phrased in the negative**, which makes it more credible than a promise: *"The agent never gets access to your raw payment credentials."* It does not say what the system protects, it says what the agent **never obtains**.

**The future is bounded and honest**: *"We're planning on expanding these controls to let people set spending limits, and choose when agents can act without additional approval"*, *"Support for agentic tokens, stablecoins, and other payment types are coming soon."* Unlike many announcements in the sector, what is shipped and what is promised are **clearly separated** — the reader knows what they can use today.

**Marker phrases**: *"agents are becoming active participants in the internet economy"*, *"making purchases across the internet remains difficult"*, *"The agent never gets access to your raw payment credentials"*, *"Today, each request requires the person's review"*, *"removes the need to build wallet infrastructure from scratch"*.

## Pense-betes

- **The sentence to remember from the whole announcement, and it contradicts its own author's camp**: *"While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today."* → **Stripe, co-author of the Agentic Commerce Protocol, publicly notes that machine-native protocols are not ready and delivers an adapter to existing card rails.** The single-use card is not an agentic payment solution: it is a **compatibility shim** that temporarily neutralizes the protocol war for the merchant, who sees only an ordinary card passing through. To be set directly against [[girard-acp-deux-protocoles-un-sigle-2026-08-02]] (three protocols for one acronym) and [[marette-agentic-commerce-optimization-acp-ucp-2026-02-23]].
- **Per-transaction approval is the core of the design — and it is an admission, not a convenience.** *"Today, each request requires the person's review before the credential is shared with your agent."* A human validates **every** expense, with the context supplied by the agent. → **As long as an agent's identity and authorization are not solved, the anchor of trust remains human and is paid for in per-transaction interruption.** This is the agent identity problem from [[uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21]] and the ambient authority from [[valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20]], not resolved but **shifted onto the human**. Direct consequence for sizing: **the model does not scale to an agent that buys frequently** — it targets the one-off, significant purchase, not the micropayment.
- **The comparison with Cloudflare Wallets is the best angle of reading, and precedence matters.** Stripe publishes on **April 29, 2026**, Cloudflare on **August 4, 2026** (cloudflare-wallets-agentic-commerce-2026-08-04) — three months later, on the same problem, with opposite choices: | | **Stripe — Link wallet for agents** | **Cloudflare — Wallets** | |---|---|---| | Rail | **cards** (single-use) + Shared Payment Token | **x402** (payment on HTTP request) | | Currency | existing cards and bank accounts | **stablecoin** | | Authorization | **per-transaction human approval** | **cap** set once, then autonomy | | Agent identity | delegated via **OAuth** from the human account | `cloudflare.pay` namespace | | Status at announcement | **shipped** (CLI, iOS/Android apps) | **handle reservation**, still in the future | | Target | consumer purchase from a merchant | agent's purchase of APIs and tools | → **Two opposite answers to the same question: Stripe bounds via repeated consent, Cloudflare via a cap consented to once.** The latter assumes agent identity is solved; the former does without it. And the comparison is instructive both ways: the principle from sfeir-code-review-anneau-contraintes-2026-07-30 — *"a loop is only entrusted with the autonomy that can be verified at low cost"* — is respected here **by the maximum price, not by the cap**: each credential is scoped by amount, currency, and merchant, so the maximum loss per transaction is bounded **even if the human approves poorly**.
- **Context as an obligation on the agent — a design detail worth reusing.** The agent must supply the reason for the expense so the human can decide: `context "Purchasing the Powdur Glow Renewal Vitamin C Serum as a gift for $35."` → **Approval is only useful if it is informed; requiring the requester to produce the justification is a pattern transposable well beyond payments** (approving a deployment, an access grant, an irreversible action). To be compared with the verifiable *exit criteria* logic of the ADLC corpus.
- **The real infrastructure product is the second layer, not the first.** *"Link's wallet for agents is built directly on top of Stripe's Issuing primitives."* **Issuing for agents** exposes the APIs to anyone wanting to build their own wallet: single-use virtual cards, fund storage, spend controls, **card-level** permissions, antifraud controls **at transaction authorization**, historical and real-time visibility. → **Stripe sells two things to two audiences: a finished wallet to consumer-facing agents, and the issuing primitives to those who want to build their own.** This is the classic platform move — occupying the product AND the layer beneath it.
- **The four use cases cited, and what they reveal about the targeted market**: (1) developers automating **their own** enterprise spend via programmatic workflows and recurring purchases; (2) **fintechs** embedding cards issued to agents to reconcile expense reports in real time; (3) **vertical SaaS platforms** issuing agentic cards to their SMB customers under their own brand; (4) **marketplaces** issuing to sellers, whose agents automate supplier payments, logistics, and procurement. → **Three of the four are B2B and go through an intermediary.** The consumer wallet serves as a showcase; **the targeted monetization is delegated issuing**.
- **Claimed distribution**: *"helps you reach Link's customer base of more than 200 million consumers"*, and the wallet *"removes the need to build wallet infrastructure from scratch"* for anyone building a consumer agent. → The argument is not technical but **about bootstrapping**: the problem with an agentic wallet is not building it, it is having users who already have a card on file. A declarative figure, not sourced in the article, and **Link's "customer base" ≠ active users of the agentic wallet** — should not be cited as adoption.
- **What the article does not say, and which must be posed as an open question**:
- **Nothing about liability for a mistaken purchase.** An agent obtains an approved credential, gets the wrong product or quantity: who bears it? The text discusses antifraud controls at authorization, never **recourse after a properly authorized transaction**. Yet this is the risk specific to agentic systems — fraud is a known problem, **mandate error is not**.
- **Nothing about Europe, or about PSD2 / strong authentication.** Does an approval in the Link app satisfy SCA? A decisive question for any European transposition, absent from the text.
- **Nothing about what the merchant sees.** A single-use card leaves the merchant unaware that an agent made the purchase — a convenience for immediate adoption, but it deprives the merchant of any agent-aware policy, running counter to what the Agentic Commerce Protocol and the Universal Commerce Protocol aim for.
- **`OpenClaw` cited as an example of a personal agent**: an uncommented mention, to be verified before reuse.
- **Meta / to link**: the most direct counterpoint to cloudflare-wallets-agentic-commerce-2026-08-04 (cards + approval vs x402 + cap); materializes on the established-rails side what ragsdale-merit-open-agentic-commerce-protocols-2026-03-19 places on the platform-protocols side; shifts onto the human the identity problem from uber-engineering-agent-identity-crisis-zero-trust-spire-2026-05-21 and the ambient authority from valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20; to be read alongside the protocol disambiguation of girard-acp-deux-protocoles-un-sigle-2026-08-02, marette-agentic-commerce-optimization-acp-ucp-2026-02-23, and google-agentic-commerce-ap2-payment-protocol-2025-09-16; order of magnitude of the addressed market in levie-building-trillions-agents-software-2026-03-07 and nrf-2026-commerce-agentique-ucp-deep-research-2026-01-13; another facet of Stripe as a user of agents in gray-stripe-minions-coding-agents-part1-2026-02-09.

## RésuméDe400mots

Announcement published on the **Stripe** blog on **April 29, 2026** by **Dan Hill**, Product Manager Link Consumer Product, following on from the **Stripe Sessions 2026** keynote: **Link's wallet for agents**, built on **Issuing for agents**.

**The diagnosis.** Agents have become capable, but buying things on the internet remains difficult for them. And above all: *"While machine payments protocols are still gaining adoption, agents need to work with the payment options sellers and consumers use today."* Coming from the **co-author of the Agentic Commerce Protocol**, the statement is notable — Stripe acknowledges that machine-native protocols lack the required traction and delivers an **adapter to existing rails** instead.

**The mechanism.** The consumer grants the agent access to their Link wallet via a **standard OAuth flow**. The agent then issues a *spend request* and obtains either a **single-use card**, or a **Shared Payment Token**, backed by the cards and bank accounts already on file. *"The agent never gets access to your raw payment credentials."* The credential is **scoped** by amount, currency, and merchant, and the agent must attach the transaction's **context** — the CLI example concerns a $35 serum bought as a gift. The consumer approves on the web or in the **new Link iOS and Android apps**, then tracks spending and manages connected agents.

**The constraint is owned as such**: *"Today, each request requires the person's review before the credential is shared with your agent."* A **per-transaction** human approval. Spending limits and cases of action without additional approval are **announced, not delivered** — as are *agentic tokens*, stablecoins, and other payment methods.

**The second layer.** **Issuing for agents** opens the Issuing APIs to anyone building their own agentic wallet: single-use virtual cards, fund storage, spend controls, card-level permissions, **at-authorization** antifraud controls, real-time visibility. Four use cases are cited — internal spend automation, cards embedded at **fintechs** for expense management, **vertical SaaS platforms** issuing to SMB customers under their own brand, **marketplaces** whose selling agents pay suppliers and logistics. Three out of four are B2B: **the targeted monetization is delegated issuing**, with the consumer wallet serving as showcase and bootstrap — Link claims **more than 200 million consumers**.

**Reservations.** Per-transaction approval is presented as a convenience when it is actually **an admission that delegated agent authorization is not solved**; it effectively rules out micropayments. The article is also silent on **liability for a mistaken but properly authorized purchase**, on **European compliance** (PSD2, strong authentication), and on the fact that the merchant, seeing only an ordinary card, loses any agent-aware policy.

## GrapheDeConnaissance

- Stripe —publie→ Link wallet for agents (TECHNOLOGIE, 0.98)
- Stripe —publie→ Issuing for agents (TECHNOLOGIE, 0.97)
- Dan Hill —travaille_chez→ Stripe (ORGANISATION, 0.96)
- Dan Hill —affirme_que→ les protocoles de paiement machine-natifs gagnent encore en adoption, donc les agents doivent composer avec les moyens de paiement utilisés aujourd'hui (CITATION, 0.97)
- Link wallet for agents —est_basé_sur→ Issuing for agents (TECHNOLOGIE, 0.97)
- Link wallet for agents —utilise→ carte à usage unique (CONCEPT, 0.96)
- Link wallet for agents —utilise→ Shared Payment Token (TECHNOLOGIE, 0.95)
- Link wallet for agents —utilise→ OAuth (TECHNOLOGIE, 0.94)
- carte à usage unique —permet→ à un agent de payer sans jamais accéder aux identifiants de paiement bruts du consommateur (AFFIRMATION, 0.97)
- carte à usage unique —résout→ l'incompatibilité entre agents et rails de paiement existants, sans attendre l'adoption d'un protocole machine-natif (AFFIRMATION, 0.9)
- justificatif de paiement scopé —réduit→ la perte maximale d'une transaction agentique, le montant, la devise et le marchand étant bornés à l'émission (AFFIRMATION, 0.94)
- approbation humaine par transaction —fait_partie_de→ Link wallet for agents (TECHNOLOGIE, 0.97)
- approbation humaine par transaction —s_oppose_à→ le micropaiement agentique, dont la fréquence rend la revue humaine impraticable (AFFIRMATION, 0.86)
- approbation humaine par transaction —est_instance_de→ une ancre de confiance restée humaine faute d'autorisation déléguée d'agent résolue (AFFIRMATION, 0.88)
- contexte de transaction fourni par l'agent —permet→ à l'humain d'approuver une dépense en comprenant ce qu'il autorise (AFFIRMATION, 0.95)
- Issuing for agents —permet→ à une entreprise de bâtir son propre portefeuille agentique avec contrôles de dépense, permissions par carte et antifraude à l'autorisation (AFFIRMATION, 0.96)
- Issuing for agents —s_applique_à→ l'émission de cartes agentiques par les fintechs, les plateformes SaaS verticales et les places de marché (AFFIRMATION, 0.94)
- Link wallet for agents —s_applique_à→ les agents personnels grand public effectuant un achat autorisé pour le compte de leur utilisateur (AFFIRMATION, 0.95)
- OpenClaw —utilise→ Link wallet for agents (TECHNOLOGIE, 0.85)
- Stripe —a_créé→ Agentic Commerce Protocol (TECHNOLOGIE, 0.93)
- Link wallet for agents —concurrence→ Cloudflare Wallets (TECHNOLOGIE, 0.88)
- Link wallet for agents —s_oppose_à→ le pari sur un rail machine-natif, en adossant la dépense agentique aux réseaux de cartes existants (AFFIRMATION, 0.89)
- Stripe —mesure→ plus de 200 millions de consommateurs dans la base clients de Link (MESURE, 0.8)
- Stripe Sessions 2026 —référence→ Link wallet for agents (TECHNOLOGIE, 0.9)
- limites de dépense sans approbation —est_instance_de→ une capacité annoncée mais non livrée au 29 avril 2026 (AFFIRMATION, 0.94)

---
Canonical: https://www.thekb.eu/en/fiches/hill-stripe-link-wallet-agents-issuing-2026-04-29/