One-Time Use Cards vs. Shared Payment Tokens: Which Stripe Architecture Is Right for Agent Commerce?
Stripe offers two paths for agent payments. One is a bridge to the old web; the other is machine-native. Here's when to use each.
Two Architectures, One Decision You Can’t Afford to Get Wrong
You are building an AI agent that needs to buy things. Stripe gives you two paths: a one-time use card or a shared payment token. Pick the wrong one and you either ship something that breaks on half the merchants your agent will ever encounter, or you build infrastructure your users aren’t ready to trust yet. The difference between these two approaches — one-time use card as adapter for the existing commercial internet versus shared payment tokens as a machine-native rail — is not a minor implementation detail. It is a structural decision about which version of the web your agent is actually designed to operate on.
This distinction is the center of gravity in Stripe’s Sessions announcements, even if most of the coverage got distracted by the demo where an agent buys coffee. The coffee demo is legible. It looks like the future. It is not the interesting part.
The interesting part is what Stripe is actually building underneath it, and what that means for anyone writing agent code today.
The Two Paths Stripe Is Offering (And Why They’re Not Interchangeable)
Stripe’s Link wallet for agents works like this: a user grants an agent programmatic access to Link. The agent creates a spend request. The user approves it. Link returns either a one-time use card or a shared payment token. The agent never sees raw payment credentials.
How Remy works. You talk. Remy ships.
That last sentence is the same in both cases. Everything else is different.
A one-time use card is exactly what it sounds like — a virtual card number scoped to a single transaction. The agent takes that card number and uses it to check out on any merchant that accepts cards. Which is most of the internet. The merchant sees a card payment. Nothing about the transaction signals that a machine made it. The merchant’s checkout flow doesn’t need to change. The merchant doesn’t need to know Stripe exists.
A shared payment token is a credential that a merchant accepts programmatically. It’s not a card number. It’s a machine-readable authorization that can carry scope — bounded by amount, merchant, currency, approval state, expiration. The merchant has to be set up to receive it. The transaction is machine-to-machine from the start.
These are not two ways to do the same thing. They are designed for two different versions of the commercial internet.
The Dimensions That Actually Matter When Choosing
Before getting into the specifics of each approach, here are the axes worth evaluating them on. Not theoretical axes — the ones that will actually bite you in production.
Merchant compatibility. How much of the web can your agent transact with, right now, without requiring the merchant to change anything?
Scope and control. How precisely can you bound what the agent is authorized to spend, where, and under what conditions?
Fraud surface. What attack patterns does each credential type expose, and how does the payment network defend against them?
Billing model fit. Does the payment mechanism match the consumption pattern — one-time purchase, streaming usage, outcome-based charge?
Trust chain complexity. How many parties need to verify what before the transaction clears?
These five dimensions tell you most of what you need to know. The rest is implementation detail.
One-Time Use Cards: The Adapter That Actually Works Today
The honest case for one-time use cards is that they work on the web as it exists, not the web as it might exist in three years.
Every merchant that accepts Visa or Mastercard accepts a one-time use card. That is not a small thing. The commercial internet was built around card rails. If your agent needs to book a hotel, buy a domain, order supplies, or pay for any service that has a normal checkout page, a scoped virtual card lets it do that without requiring the merchant to adopt any new protocol. The agent acts. The merchant receives a card payment. Done.
This is what the source material means by “adapter for the existing commercial internet.” It is not a compliment and it is not an insult. It is a precise description of the architectural role. An adapter lets two incompatible systems talk to each other. One-time use cards let machine-driven purchasing intent flow through infrastructure that was designed for humans.
Built like a system. Not vibe-coded.
Remy manages the project — every layer architected, not stitched together at the last second.
The fraud properties are also meaningful. Because the card is scoped to a single transaction, a stolen credential has limited blast radius. Stripe’s Radar announcement specifically addresses token theft defenses for agent-based fraud patterns — and the one-time use card is part of that defense posture. The credential expires. It can’t be reused. A fraudster who intercepts it gets one shot at one transaction.
The control model is simpler than shared tokens, which is both a feature and a limitation. You can bound the card by amount. You can require user approval before the credential is issued. Stripe says they plan to expand controls so users can set spending limits and decide when agents can act without fresh approval each time. But today, the scoping is relatively coarse compared to what shared tokens can carry.
The billing model fit is also limited. One-time use cards are good at capturing a single moment of intent. They are not good at representing ongoing mandates — “spend up to $100 finding the best supplier,” “pay per query as usage accumulates,” “charge when the outcome passes an eval.” Those patterns require something that can stretch across time and settle continuously. A one-time use card is, by definition, one time.
There is also a latency and UX cost. Every transaction that requires a fresh user approval is a human in the loop. For tasks where that’s appropriate — a large purchase, a new merchant, anything outside established parameters — that’s a feature. For high-frequency, low-value agent actions, it becomes friction that defeats the purpose of having an agent at all.
Shared Payment Tokens: The Machine-Native Rail That Requires a Machine-Native World
Shared payment tokens are what Stripe’s machine payments protocol is actually pointing toward. They are not an adapter. They are a native credential for a world where agents and services coordinate payment directly, without a human-facing checkout page in the middle.
The token carries scope. It can be bounded by merchant, by amount, by currency, by credential type, by approval state, by expiration. A seller who accepts shared payment tokens can verify programmatically that this purchasing attempt is authorized, scoped correctly, and coming from a legitimate agent acting within its mandate. The transaction is machine-readable from the start.
This matters enormously for the billing patterns that AI consumption actually creates. Stripe’s streaming payments work — Metronome for precise usage tracking and Tempo for stablecoin micro-payments — is designed for exactly this shape of transaction. If an AI product incurs cost at the moment tokens are burned, settling at the end of the month creates real risk. The business already paid for compute. The customer might not pay. The fraudster might disappear. Shared payment tokens, combined with real-time metering and dimensional pricing, let you settle closer to when cost is incurred.
The agentic commerce suite Stripe announced is built around this model. Dimensional pricing, hybrid pricing, commits, real-time metering — these are billing primitives for AI consumption. They don’t map cleanly onto a one-time use card. They need a credential that can represent an ongoing mandate, not a single transaction. The model capabilities being compared across GPT-5 and Claude Opus are converging on a world where agents are making real economic decisions at scale, and the payment architecture underneath those decisions needs to match the consumption shape those models create.
Coding agents automate the 5%. Remy runs the 95%.
The bottleneck was never typing the code. It was knowing what to build.
The fraud surface is different too, and not uniformly better. Stripe Signals extends risk information beyond direct Stripe transactions — it can see payment behavior, business behavior, signup behavior, and now agent behavior across a large portion of the internet economy. That network-level visibility is what makes shared tokens defensible against the fraud patterns already emerging. The source material is direct about this: there are already a few thousand humans running millions of agents to register fraudulent accounts and steal tokens. That is not a future threat. It is a current one.
But shared payment tokens require merchant readiness. The merchant has to be set up to accept them. That is a real constraint today. Most of the commercial internet is not set up to accept machine-native payment credentials. OpenAI and Stripe co-developed the agentic commerce protocol, which is early infrastructure work toward a world where more merchants can receive these credentials — but “early infrastructure work” is an honest description of where things stand.
Visa and Mastercard are building their own agent payment and token systems. Microsoft has pushed shopping inside Copilot. PayPal is building commerce services around wallet trust and merchant protection. The whole market is running toward the same place, which means merchant adoption of machine-native credentials will accelerate. But it hasn’t happened yet.
If you are building an agent today that needs to transact with arbitrary merchants on the open web, shared payment tokens will fail on most of them. That is not a reason to ignore them. It is a reason to understand which part of your architecture they belong in.
When to Use Each One
Here is the practical breakdown, without hedging.
Use one-time use cards when:
Your agent needs to transact with merchants who haven’t adopted any new protocol. This is most merchants, today. If the use case involves booking, ordering, or purchasing from the general commercial internet — hotels, domains, supplies, services with normal checkout flows — the one-time use card is the right tool. It works now. It doesn’t require the merchant to change anything. The fraud properties are acceptable for bounded, user-approved transactions.
Also use one-time use cards when the transaction is genuinely one-time and the user wants explicit approval before each purchase. The credential model matches the intent model.
Use shared payment tokens when:
Your agent is operating within a closed ecosystem where merchants are already set up to receive machine-native credentials. This includes Stripe-native merchants, platforms built on the agentic commerce suite, and any merchant who has explicitly opted into the machine payments protocol.
Also use shared payment tokens when the billing model is usage-based, streaming, or outcome-based. If you are building an AI product that meters consumption in real time — per token, per query, per minute, per resolved ticket — shared tokens combined with Metronome’s usage tracking and Tempo’s micro-payment settlement are the right architecture. One-time use cards are not designed for that shape of transaction.
Use shared tokens when you need fine-grained scope that persists across multiple interactions. If the agent has a mandate — “spend up to $500 on research over the next two weeks” — a shared token can carry that mandate in a way a one-time use card cannot.
The honest middle case:
Other agents start typing. Remy starts asking.
Scoping, trade-offs, edge cases — the real work. Before a line of code.
Most production agents will use both. One-time use cards for the open web. Shared tokens for the machine-native layer. Stripe is explicitly bridging both, which is how infrastructure transitions actually happen. The future doesn’t arrive by replacing every old surface at once. It arrives through adapters that let new behavior coexist with old infrastructure while the native layer matures.
If you are building agent workflows that need to coordinate across both layers, MindStudio handles the orchestration complexity — 200+ models, 1,000+ integrations, and a visual builder for chaining agents and workflows — so you can focus on the payment architecture decisions rather than the plumbing underneath them.
The Brand Question Nobody Is Asking About Payment Architecture
There is a downstream consequence of this architectural choice that most builders are not thinking about yet.
When an agent pays with a one-time use card, the merchant sees a card payment. The merchant has no signal that a machine made the purchase. The merchant cannot distinguish an agent-driven transaction from a human-driven one. That means the merchant cannot optimize for agent-driven buyers, cannot expose agent-readable metadata, cannot build the kind of commercially complete surface that makes agents want to return.
When an agent pays with a shared payment token, the merchant knows. The transaction is machine-readable from the start. The merchant can respond accordingly — surfacing structured product data, policies, fulfillment constraints, the intent hooks that let the agent map a buyer’s fuzzy preference to a specific product.
This is where the brand question gets interesting. The old brand question was how to make the buyer feel something at the point of persuasion. The new brand question is how to become the kind of business the buyer’s agent remembers as a good answer. That shift is not visible as a checkout button. But it is one of the bigger distribution changes coming, because the seller’s persuasion surface is being replaced by the buyer’s preference layer.
Merchants who accept shared payment tokens are, in effect, opting into that new game. They are saying: I am legible to machines. I can be called programmatically. My commercial reality is explicit enough for an agent to act on it.
Merchants who only ever receive one-time use cards may not even know agents are buying from them. That is fine for now. It will become a problem when agents start preferring merchants who can be called directly.
For builders thinking about how to expose their own services to agents — not just how to build agents that buy things — this is the architectural question worth sitting with. Agentic workflows that chain models and tools together are already becoming standard. The payment layer is the last piece of that stack to become machine-native, and it is becoming machine-native now. Understanding how open-weight models like Gemma and Qwen perform in agentic settings is increasingly relevant here too, because the model running your agent determines how reliably it can interpret scoped credentials, handle approval flows, and recover from payment failures without human intervention.
The Fraud Reality You Cannot Ignore
One more thing before you ship.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
The fraud patterns Stripe’s Radar is defending against are not hypothetical. The source material is explicit: a few thousand humans are already running millions of agents to register fraudulent accounts and steal tokens. In traditional SaaS, a fraudulent free-trial user clicking around the product was nearly free — one more row in a database. In AI SaaS, one fraudulent free-trial user costs real money dollar-for-dollar in compute. They are burning tokens. They are stealing directly from the margin.
This changes the calculus on both credential types. One-time use cards have limited blast radius per credential, but they do not prevent fraudulent account registration. Shared payment tokens, backed by Stripe Signals’ network-level risk data, can carry more trust signal — but they require the merchant to be set up to read that signal.
The fraud defense is not a feature you add later. It is part of the architecture from the start. If you are building on shared payment tokens, understand what Stripe Signals is doing and how Radar’s token theft defenses apply to your specific transaction patterns. If you are building on one-time use cards, understand that the fraud surface shifts from credential theft to account-level abuse.
When thinking about how to build the application layer on top of these payment primitives, Remy takes a spec-driven approach — you write annotated markdown describing your application’s rules, edge cases, and data types, and it compiles a complete TypeScript backend, database, auth, and deployment from that spec. The spec becomes the source of truth for fraud rules and authorization logic, not just the happy path. For payment-adjacent applications where the authorization model is complex, having the entire backend generated from a single auditable spec is a meaningful advantage over assembling it piecemeal.
The agentic workflow patterns emerging from open-source agent projects and the model capabilities being compared across frontier labs are converging on a world where agents are making real economic decisions at scale. The payment architecture underneath those decisions matters more than most builders currently appreciate.
The Transition Is Already Happening
Stripe is not betting on one of these architectures winning. It is building both because the transition will be uneven. One-time use cards let agents operate against the human-built web. Shared payment tokens and the machine payments protocol point toward a web where agents and services coordinate payment directly.
Most companies will live between those worlds for a while. The right question is not which architecture is better in the abstract. The right question is which part of the web your agent needs to operate on, what billing model matches your consumption pattern, and how much merchant readiness you can assume.
Answer those three questions honestly and the choice becomes straightforward. The infrastructure is there. The fraud defenses are being built. The merchant adoption is lagging but accelerating.
Build for where the web is. Design for where it’s going.
