EDITORIAL ARTICLE
Stripe Link Agent Wallet: Paying Without Giving an Agent Your Card Details
The takeaway: Stripe’s Link Agent Wallet builds on a user’s existing cards or bank accounts and provides an agent with a one-time card or scoped payment credential. Its aim is to connect agents to existing payment infrastructure. Stripe’s public demonstration includes user approval; it does not establish that unattended shopping is generally supported.
Sources reviewed October 28, 2026. We did not open a Link account or make a payment.
Why an agent wallet?
Stripe provides merchant payments, acquiring, issuing and other financial infrastructure; Link is its consumer payment experience. In its April 2026 announcement, Stripe described Link Agent Wallet as built on Issuing for agents. It gives an agent a one-time card or Shared Payment Token (SPT) without exposing the user’s original payment credentials.
Unlike a stablecoin wallet, the user may already have a usable card or bank account. The challenge is allowing the agent to use it within appropriate boundaries and fitting the transaction into merchant payment flows. Link, issuing, merchant acquiring and the agent application play distinct roles.
From chat to a $2 API payment
Stripe’s Sessions demonstration shows an agent finding a paid API supporting Machine Payments Protocol (MPP), seeing a $2 price, sending the user to Link for review and approval, then continuing the request. This is a public demo, not our independent verification, and it does not establish that every agent purchase follows this process.
This diagram conceptualizes the public demonstration and product description. Messages, approval timing and credential types depend on the implementation.
Why use a one-time card or SPT?
| Problem | Product approach | What not to assume |
|---|---|---|
| Agent needs to pay | Use a one-time card or SPT | The agent must know the original card number |
| User wants purchase visibility | User approval in the demo | Every service has the same approval experience |
| Merchant needs payment | Connect to applicable payment and merchant flows | Every website, region and bank account is supported |
| A dispute occurs | Follow applicable merchant and payment rules | The wallet guarantees quality or a refund |
Payment credentials, user authorization and issuer approval are separate. Even after a user agrees, the issuer, merchant or payment provider can decline, and additional identity verification may be required.
Pricing and business model
Stripe already operates merchant payments and Issuing. Connecting agent purchases to existing networks could create additional payment and service opportunities; this is not a disclosure of Agent Wallet revenue. Stripe’s general pricing applies to particular payment products and is not necessarily one universal Agent Link fee. Check consumer, merchant, issuing and credential contracts and regions separately.
| Cost or responsibility | Questions |
|---|---|
| User payment | Are card, bank or conversion fees charged, and who pays? |
| Merchant payment acceptance | Who charges and at what rate for Link, SPT or virtual cards? |
| Disputes and refunds | What are the merchant, issuer and platform each responsible for? |
| Eligibility | Which accounts, regions, agent platforms and merchants are supported? |
Comparison with on-chain agent wallets
Link’s existing credentials may be attractive for buying from card-accepting merchants. Coinbase or Circle may provide more direct paths for machine payments to compatible on-chain APIs, depending on the integration. Merchant support, user approval and total cost still determine fit.
To verify: eligible countries and accounts; when each purchase requires approval; the merchants supported by SPT and one-time cards; limit enforcement; and what happens when payment succeeds but service delivery fails. One demonstration does not establish universal availability.
Where does the money come from, and what does the agent see?
Stripe’s announcement identifies a user’s existing card or bank account as a funding source. After approval, a one-time card or SPT is provided to the agent so the original credential need not be shared. Stripe also says users can view agent spending and manage connected agents in Link.
That differs from continuously exposing a full card number. The effect of a leaked credential still depends on its actual restrictions. Scoped is not risk-free: the agent may ask approval for the wrong merchant or amount, and a user may accept without understanding the authorization window or final price.
Stripe’s Agentic Commerce guide says an SPT can be scoped to a seller, amount and time window, and Link Agent Wallet purchases require user review and approval. Confirm how a specific integration handles failures, order changes, price changes and expired credentials; do not assume any token can be reused indefinitely.
Link and Issuing: consumer experience and developer infrastructure
Stripe describes Link Agent Wallet as built on Issuing for agents. Link is the consumer payment experience; Issuing gives business developers infrastructure for cards, funding, permissions and transaction monitoring. A team may build its own product around Issuing, but not every Issuing customer uses Link, nor can every region issue cards immediately.
| Decision maker | Link wallet question | Custom Issuing question |
|---|---|---|
| User | Approve this purchase? | How can cards and spending be viewed? |
| Agent application | How are merchant, product and amount represented? | Must it build a UI, budgets and notifications? |
| Stripe and payment partners | How are scoped credentials created and handled? | Are card, funding and risk services available? |
| Merchant | Accept payment and deliver? | How are authorization, capture, refunds and support handled? |
Stripe’s October 2026 service terms describe Link Agent Wallet as a Preview and specify conditions for business integration and Link as a payment method. The terms page’s region can affect applicability; check the relevant local version and agreement. Preview describes a service stage, not approval for a particular customer.
Estimating the full cost
Suppose an agent buys $100 software. The user’s final price may include merchant taxes or currency conversion; the merchant may also incur processing costs under its Stripe contract. A public general price cannot simply be multiplied by $100 and presented as the definite fee for this agent transaction: location, card type, issuing arrangement and contract can change it.
Request an itemized breakdown of product price and tax, exchange rate and conversion, user-side fees, merchant processing fees, issuing costs and treatment of fees on refunds. For frequent $1 API calls, fixed charges and approval frequency may affect economics; a low price does not make a card path suitable for all micropayments.
Failures, refunds and user experience
If the user declines, the agent should leave the task in an explainable pending state rather than switching to an unauthorized method. If the issuer declines after user approval, describe a failed payment rather than saying the user did not authorize it. If payment succeeds but an API returns no result, check transaction and order status before retrying or requesting a refund under merchant rules.
The Stripe and Meta Muse case illustrates consumer shopping, but its channel and geography should not be generalized to every agent and merchant. Fit depends on whether users accept each approval, target merchants are supported, and order and support workflows are coherent—not just whether the user has a card.