Jun 22, 2026Reviews

Stripe Link Agent Payments: How AI Agents Can Buy With User Approval

An agent that can search, compare, and fill a checkout form still hits the same hard boundary: payment credentials. Handing an agent a primary card number makes the agent a liability. Making a human re-enter card details at every step cancels the autonomy. Stripe’s Link agent wallet is an attempt to occupy the narrow space between those two failures.

The wallet lets a Link user authorize an agent to request a payment credential without exposing the user’s underlying card or bank-account details. The agent creates a spend request with merchant, amount, and context. The user reviews it. Only after approval does Link return a scoped credential for that purchase.

That makes the product useful today for supervised agent commerce, not unsupervised spending. The approval step is part of the security model. An operator who treats it as temporary friction will design the wrong workflow; an operator who treats it as a clear consent checkpoint can build a practical and auditable one.

Overview

Stripe launched Link’s wallet for agents on April 29, 2026, built on its new Issuing for agents primitives. The consumer-facing Link wallet is the faster path for a personal agent that needs to spend from a user’s saved payment methods. Issuing for agents is the lower-level option for businesses that need to build their own wallet, card program, fund flow, and controls.

The launch also sits inside Stripe’s broader agentic-commerce push. Stripe has been positioning agent payments, product discovery, checkout, fraud detection, and machine-readable payment flows as connected infrastructure rather than one-off wallet features. That matters because Link is the buyer-side control point, while protocols such as MPP and products such as Issuing for agents address different parts of the same emerging commerce stack.

After a user grants an agent access through Link’s OAuth flow, the agent can create a spend request for either a one-time-use virtual card or a Shared Payment Token (SPT). The credential can be limited by amount, currency, and merchant. The user approves the request in Link before the credential is shared with the agent, then can track agent spending and manage connected agents in Link.

Stripe’s launch materials describe the wallet as a bridge between ordinary web checkout and machine-native payment flows. A virtual card can be used in a conventional checkout form. An SPT is for a merchant that accepts programmatic payment through the Machine Payments Protocol, or MPP. The two paths serve different checkout environments, so choosing a credential type belongs in the agent’s plan rather than at the last second.

Availability and Supported Clients

The public Link CLI documentation says the agent wallet is currently available only to US Link accounts. Stripe’s broader Agentic Commerce page also labels the current product surface US-only. Do not promise global availability, stablecoin funding, or automatic spending limits unless Stripe confirms them for the exact account and integration.

Surface	Current role	Practical constraint
Link web	Connects an account and approves spend requests.	The documented request-approval flow pauses for user approval; delegated or pre-approved flows must carry explicit approval details.
Link iOS and Android apps	Receive and approve spend requests; manage connected agents.	Treat mobile approval as an asynchronous pause in the agent workflow.
Link CLI	Lists payment methods, creates requests, retrieves approved credentials, and pays MPP merchants.	Requires a US Link account.
Link CLI skill	Adds the CLI as a skill for agent environments.	Install with `npx skills add stripe/link-cli`; verify the host’s permission model.
Local MCP server	Exposes Link CLI to an MCP-capable client.	Keep the process local and protect its configuration and output paths.
OpenClaw and other personal agents	Stripe names OpenClaw as an example personal agent.	Stripe does not publish a universal certification list for every agent host. Test the exact integration.

The CLI’s agent mode uses compact, LLM-friendly output by default in non-interactive environments. It can also emit JSON, YAML, Markdown, or JSONL. That makes it an integration surface, not merely a terminal convenience.

How the Authorization Flow Works

The Link agent wallet separates user authorization from purchase execution.

The agent or operator runs link-cli auth login and receives a verification URL plus a short phrase.
The user opens the URL, signs into Link, and enters the phrase to approve the connection. A --client-name value identifies the connecting agent in the approval experience.
The agent lists the user’s saved payment methods and, if needed, shipping addresses.
The agent creates a spend request with payment method, merchant name and URL, amount, currency, context, and optional line items and totals.
The agent requests approval. Link notifies the user, who approves or denies on the web or mobile app.
After approval, Link returns either a virtual card or an SPT. The agent uses that credential to complete the purchase.
The workflow records the final outcome, then removes any temporary credential material from its process and logs.

The crucial distinction is between a user’s original payment credential and the purchase credential. Link does not give the agent the underlying card or bank-account details saved in the wallet. After approval, the agent can receive the details of the issued virtual card needed to perform a conventional checkout. That temporary card is still sensitive information. “Scoped” is not the same as “safe to print in an agent transcript.”

Credential Handling

The Link CLI’s default behavior reflects that risk. Retrieving an approved spend request does not include card details by default. To retrieve them, the caller must request --include card. Stripe recommends --output-file to write the full card object to a local file with 0600 permissions while standard output keeps only redacted fields such as brand, last four digits, and expiry.

Use a dedicated execution boundary for the payment step:

link-cli spend-request retrieve lsrq_001 \
  --include card \
  --output-file /secure-runtime/link-card.json \
  --format json

The agent that decides to buy and the process that submits card details do not need the same access. Keep the virtual-card file out of chat history, source control, generic logging, screenshots, and support exports. Delete it after the payment result is durably recorded. A one-time card reduces blast radius; bad handling can still turn a narrow credential into a needless incident.

Spend Requests and Payment Types

Every spend request needs merchant details, context, and amount. The CLI documents merchant_name, merchant_url, context, and amount as required; payment_method_id is optional and can fall back to the default or first eligible payment method. The CLI requires at least 100 characters of context, an amount no greater than 500,000 cents, and a three-letter ISO currency. Those are real integration constraints, not prompt-writing suggestions.

link-cli spend-request create \
  --payment-method-id csmrpd_xxx \
  --merchant-name "Example Merchant" \
  --merchant-url "https://merchant.example" \
  --context "Buying one annual research subscription requested by the user for competitive analysis. The total is within the approved budget and the merchant, product, renewal terms, and price have been reviewed." \
  --amount 3500 \
  --line-item "name:Research subscription,unit_amount:3500,quantity:1" \
  --total "type:total,display_text:Total,amount:3500" \
  --request-approval

Credential	Where it works	Operating rule
One-time virtual card	Standard web checkout forms, including sellers that do not use Stripe or Link.	Handle the issued card as a short-lived secret; submit once, then remove it.
Shared Payment Token	A merchant that accepts MPP and Stripe’s payment method.	The SPT is one-time use; a failed payment needs a new spend request.

An SPT is a machine-native payment primitive. It can be scoped to a seller, bounded by time and amount, and observed across its lifecycle. Stripe says its Radar signals can be applied when an SPT is used on Stripe. That makes it the cleaner option when both agent and merchant support the protocol; it does not make it universally usable yet.

Fees and Pricing

Stripe’s public pricing page lists $0.15 per SPT issued. It also lists Link’s normal payment-method processing prices, including standard domestic-card pricing starting at 2.9% plus 30¢ per successful charge and Instant Bank Payments starting at 2.6% plus 30¢. Those are merchant processing prices, not a published consumer fee for granting an agent wallet access.

Stripe does not publish a standalone public price for Link’s agent-wallet connection or a public price for a one-time virtual card issued through the Link CLI. Treat those as sales, account, or contract questions before designing unit economics around them. Do not infer that a virtual card is free because the SPT fee is published, or that normal Link checkout pricing automatically describes every agent-wallet transaction.

Cost question	Public answer	Operator action
SPT issuance	$0.15 per issued SPT.	Count failed attempts because a failed SPT payment requires a new request.
Link payment method	Standard Link processing rates are published.	Confirm which party is merchant of record and pays processing fees.
Agent-wallet or virtual-card access	No standalone public price found.	Get written confirmation from Stripe for the account and use case.
Agentic merchant integration	Pricing can depend on the product and contract.	Separate buyer-wallet cost from seller-side acceptance cost.

How It Compares

“Agentic payments” describes several different problems. Link’s wallet for agents is a user-authorized buyer wallet. It should not be compared as if it were the same product as a merchant acceptance protocol or a business’s internal card program.

Approach	Best fit	Control model	Trade-off
Link agent wallet + virtual card	A personal agent buying from an ordinary web merchant.	User approves each request; card is one-time use.	Works with conventional card checkout, but requires credential handling after approval.
Link agent wallet + SPT	An agent paying an MPP-capable merchant.	User approves each request; token is scoped and one-time use.	Cleaner programmatic flow, but merchant protocol support is required.
Stripe Issuing for agents	A business, marketplace, or platform building its own agent wallet.	Builder designs onboarding, funding, card-level controls, and fraud controls.	More flexibility and responsibility; Stripe presents it as the underlying infrastructure for customized agentic wallets and cards.
Stripe agent toolkit with restricted API keys	An agent operating a business’s own Stripe account.	Restricted keys limit which Stripe operations the agent can call.	Appropriate for creating or managing Stripe objects, not for letting a consumer agent spend from a personal wallet.
Direct primary-card access	A shortcut that exposes raw credentials to an agent.	Weak or absent separation.	Avoid. It defeats the wallet’s central security benefit.

The competitor question should begin with the direction of money. If the agent is spending the user’s money, Link provides a consumer-approval and credential-abstraction layer. If the agent is operating a company’s Stripe account, restricted API keys and the Stripe agent toolkit are the relevant control surface. If the merchant wants to accept programmatic payment, MPP and SPT support are the relevant question.

Workflows Worth Copying

Supervised Shopping

The agent researches a defined item, presents merchant, price, delivery, and return terms, then creates a spend request only after the user selects an option. The approval screen becomes a final confirmation, not the first time the user sees what the agent plans to buy.

Bounded Subscription Purchase

The agent gathers pricing and renewal terms, creates a request with full context and line items, and waits for approval. Record the renewal date and cancellation path in the durable purchase record. Payment success is not the end of the workflow when a recurring obligation is involved.

MPP Service Payment

For an MPP-capable seller, create an SPT request, obtain approval, and call link-cli mpp pay. Store the request ID, merchant endpoint, response status, and receipt reference. If the payment fails, stop and create a new request; never try to reuse the token.

Human-in-the-Loop Provisioning

An infrastructure or development agent can prepare a proposed purchase, evidence, and a spend request. It should not continue to provision a paid service until approval and payment success are confirmed. This prevents an agent from creating an orphaned bill after a payment denial.

Starter Prompts

Use the following prompts before the payment command, not as a replacement for user approval.

Research [product or service] for this exact need: [need]. Return three options with
merchant, total price, renewal terms, delivery or activation timing, return or cancellation
policy, and source URLs. Do not create a spend request or make a purchase.

Prepare a purchase brief for [selected option]. Include merchant URL, line items, total,
currency, evidence that the amount is within the user’s stated budget, and a 100-plus-character
approval context. Stop before creating a spend request.

Create a Link spend request only after I confirm this brief. Use a one-time virtual card unless
the merchant has confirmed MPP support. Request approval, poll for a terminal state, and report
only the request ID, status, merchant, amount, and receipt reference. Never print card details.

For this MPP-capable endpoint, create a Shared Payment Token spend request and ask for approval.
After approval, execute one payment attempt. If it fails, stop, record the failure, and do not
reuse the token or retry with a new request unless I approve a new attempt.

Troubleshooting

Symptom	Likely cause	First response
Login remains incomplete	The user has not approved the verification URL and phrase.	Keep the agent in a waiting state; do not repeatedly start new login flows.
Spend request is rejected at creation	Missing required field, context below 100 characters, invalid ISO currency, or amount above 500,000 cents.	Validate the request locally before submission.
Request remains pending	User approval is outstanding.	Notify once with merchant, amount, and purpose; poll with a finite timeout.
Approved request has no usable card	Retrieval omitted `--include card`, or the credential output was intentionally redacted.	Use the secure output-file pattern; never expose it in standard logs.
MPP payment fails	The SPT is one-time use or the merchant endpoint rejected the request.	Record the result and create a new request only with user approval.
Merchant cannot accept the credential	The seller does not support MPP, or a conventional checkout rejects the virtual card.	Select the correct payment path and do not fall back to the user’s primary card.
Agent loses authorization	User revoked access or authentication state changed.	Stop purchasing activity and ask the user to reconnect through Link.

Gotchas

The documented request-approval flow pauses for human review. If using delegated or pre-approved flows, pass explicit approval details and keep an auditable consent record.
The 500,000-cent maximum is a Link CLI spend-request constraint. Do not split a larger purchase into artificial fragments to bypass it; ask for a different, approved payment path.
The issued virtual card is sensitive even though the original payment credential remains hidden. Keep it out of prompts, logs, and transcripts.
Payment authorization does not validate the agent’s decision. The agent can still select the wrong subscription tier, seller, quantity, or renewal term. Make the approval context legible to a human.
An approved payment request does not prove the merchant checkout succeeded. Require a receipt, confirmation page, or merchant response before telling the user the purchase is complete.
SPT support depends on the merchant’s MPP implementation. A token cannot make a nonparticipating checkout programmatic.

Operator Verdict

Stripe Link’s agent wallet is a credible early pattern for consumer agent payments because it keeps the original payment credential out of the agent while preserving a human approval checkpoint. The virtual-card route gives agents reach across ordinary card checkout. The SPT route is cleaner for participating machine-native merchants.

Its limits are the point. The wallet is not a general-purpose autonomous spending account, and it should not be marketed as one. The safest public framing is supervised execution: a user authorizes an agent connection, approval is recorded before credentials are released, and the resulting activity remains visible.

Adopt it for a narrow purchase workflow where merchant, amount, purpose, and proof of completion can be captured. Wait on broad autonomous procurement until the controls, pricing, availability, and merchant protocol coverage fit the actual risk. An agent that can buy is useful. An agent that can spend without a comprehensible trail is an accounting problem waiting to happen.