Payments have always assumed a human is at the checkout. Cards, accounts and the fraud systems around them were all built on that idea, and it held together until agents started doing the spending. Now it cracks: hand a raw card number to an autonomous agent and its reasoning loop is one prompt injection away from spending money nobody approved. An agent wallet fixes this, because it is the trust boundary between the agent’s reasoning and the actual money. Here’s how it works, and how to decide whether to build it or buy it. The wider picture is the agentic commerce landscape.
How does an agent wallet work: identity, budget and spending controls?
An agent wallet bundles three things into one container: a persistent identity for the agent, a pre-funded budget, and spending controls enforced outside the model. Together they turn “the model can spend” into “the model can only spend within bounds a human approved”.
The three parts of an agent wallet
Every transaction runs one pipeline: hold funds, attest identity, check the payment against the pre-approved limits, then settle over a connected rail. Identity is the part worth understanding. Agents reuse OAuth-style scoped authorisation, and Know Your Agent (KYA) extends one-time KYC into continuous verification of who is acting.
The budget caps exposure up front. The controls do the rest: per-transaction caps, session budgets with expiry, merchant allowlists, a rolling outflow limit (a ceiling on how much can leave the wallet across a rolling window) and prompt revocation, all backed by an audit trail. Because these live at the infrastructure layer rather than inside the agent’s code, a prompt injection cannot lift them.
Issuing versus Link: programmable versus managed
This three-part design shows up concretely in the products shipping today. Stripe’s two offerings show the spectrum: Issuing for agents is a programmable API layer for building your own wallet and cards, with more control and card-rail reach, while Link’s wallet for agents grants an agent OAuth-scoped access to a user’s existing cards and accounts, faster to adopt but less customisable. Both come from Stripe’s platform. The pattern shows up beyond card networks too: cloudflare.pay gives each agent a Virtual Wallet with capped stablecoin spending, while Mastercard’s Agent Pay, built with OKX’s Agentic Wallet, targets payments initiated directly by machines.
Spending controls and limits to look for
Look at the controls layer first; the credential underneath it is secondary. The caps and allowlists are what carry the safety guarantees, and together they form the agentic commerce control layer that sits on top of the rails underneath the wallet.
What is a Shared Payment Token (SPT), and how does it avoid exposing raw card credentials?
The credential inside the wallet matters as much as the wallet itself, which is where the Shared Payment Token comes in. A Shared Payment Token is a scoped credential: a machine-readable, merchant-accepted token that carries its own amount, merchant, currency, approval state and expiry, instead of a card number. Because the scope travels with the token, neither agent nor merchant ever touches raw card data, and any loss is confined to that token’s own limits.
What the token actually carries
An SPT is issued just in time for a bounded payment session, so the agent presents an opaque token rather than a card number. The amount and expiry are enforced inside the token by the issuer, so the agent cannot spend more than it allows. That is least-privilege authorisation applied to payments.
SPTs versus one-time-use virtual cards
Compare that with a one-time-use virtual card. A virtual card is the familiar primitive: a card number scoped to one transaction, working on any merchant that accepts cards with no checkout changes. An SPT is machine-native, with no checkout page, and it supports usage-based and streaming billing that a single-use card cannot represent. The choice depends on the merchant: a one-time-use card works today on the open web, while an SPT suits merchants set up for machine-native credentials. In practice an agent may use both. Either way, the scoping question loops back to who pays when a delegated purchase goes wrong.
How do I decide whether to build agent payment infrastructure or buy it?
Once the credential and the controls are scoped, the remaining question is whether to own that layer or rent it. The build-versus-buy decision weighs four things: time-to-market, control, compliance, and the total cost to your business of running the infrastructure over its lifetime. Underneath all four sits a single question: who owns the control layer and its liability.
The four factors that decide it
Much of the build cost lives below the waterline. Hosting, maintenance, PCI scope, key management and incident response land after deployment, and every rebuild is another engineering bill. Buy, and a managed provider absorbs much of that burden in exchange for less control and some lock-in. Build, and you keep the policy and the data, but you concentrate the liability on your own team.
The rule of thumb: build only where the wallet and policy layer are a differentiator for your business, and buy the commodity parts everywhere else. Unless the policy layer is your product, you are probably in the buy camp.
What to look for in a provider
Beyond the controls already covered, weigh two more things: merchant acceptance, and, if you operate in Australia, the ASIC and AUSTRAC licensing posture. Then the question is which provider is ready to build on.
Conclusion
The agent wallet is where identity, budget and scoped credentials meet real money, and the build-or-buy decision determines who owns that control layer. The useful question is how to bound what an agent can pay, and who owns the layer that bounds it. Own that question before your agents hit it in production. We’ve covered the bigger picture in AI agent wallets and agentic commerce.
Frequently Asked Questions
Is an agent wallet just a credit card for an AI?
No. A credit card hands over a reusable payment instrument, while an agent wallet is a control layer that bundles identity, budget and scoped credentials. The card number is the thing you are trying to avoid exposing, and the wallet replaces it with limits that bound what the agent can spend, so a compromise touches the token rather than your whole account.
Do I need to store raw card numbers or long-lived credentials to let an agent pay?
No, and you should avoid it. Scoped credentials such as Shared Payment Tokens and one-time-use virtual cards let an agent transact without ever holding raw card data, because the token carries its own amount, merchant and expiry limits. The agent presents a constrained authorisation, and the underlying account details stay out of the model’s reach entirely.
What happens if an AI agent is compromised or spends on something it shouldn’t?
The damage stays inside the credential’s scope. Because controls are enforced outside the model, a prompt injection or malfunction can only spend up to the per-transaction cap, merchant allowlist and session budget a human already approved. The blast radius is the token, not the account, and the audit trail ties each transaction to an agent, mandate and budget.
What is Know Your Agent (KYA), and how does it differ from KYC?
KYA is continuous, runtime verification of an agent’s identity and authority, whereas traditional KYC is a one-time check performed when an account is opened. Know Your Agent extends that into an ongoing posture, confirming that the agent acting now is the agent you authorised, for the purpose you approved. It matters because delegated purchases happen without a human present at checkout.
What’s the difference between Stripe Issuing for agents and Link’s wallet for agents?
Stripe Issuing for agents is a programmable API layer for building a custom agent wallet and issuing cards, which gives you more control and card-rail reach. Link’s wallet for agents grants an agent OAuth-scoped access to a user’s existing cards and accounts, which is faster to adopt but offers less customisation. The trade-off is control versus speed to market.
Can I tighten or revoke an agent’s spending limits after it’s running?
Yes. Well-built agent wallets support prompt revocation and adjustable controls, so you can lower a cap, expire a session budget or remove a merchant allowlist without rebuilding anything. Because the policy layer sits outside the model, changes take effect deterministically on the next transaction rather than depending on the agent’s own reasoning or cooperation.
How do SPTs and one-time-use virtual cards handle refunds and disputes?
Both stay tied to the funding account and the merchant relationship, so refunds return through the original payment path and disputes still follow the card rail’s chargeback rules. The reference point differs: a Shared Payment Token binds to a scoped payment session and its expiry, while a one-time-use virtual card behaves like a familiar single-use card. Either way, the audit trail reconciles each transaction.
Can an agent wallet work across different currencies and countries?
Yes, though coverage depends on the provider and the credential. A Shared Payment Token can carry currency as part of its scope, and card-rail options such as Stripe Issuing inherit the reach of the underlying network. Cross-border use is therefore a matter of merchant acceptance and provider footprint, not a limitation of the wallet concept itself.
How do I test an agent wallet before letting it spend real money?
Start in a sandbox or test mode with capped, pre-funded balances. Providers such as Stripe expose test cards and simulated authorisations, and cloudflare.pay style per-agent virtual wallets let you set a small spending ceiling. Test prompt injections, expired sessions and merchant allowlists, then raise limits gradually as the controls prove predictable.
Are agent wallets regulated in Australia, and who is liable if something goes wrong?
Regulation is still catching up, with ASIC and AUSTRAC licensing reform shaping the ground rules for agentic payments. Liability depends on where the control layer sits: a managed provider absorbs part of the compliance burden and exposure, while building in-house concentrates it on your team. That is why the build-or-buy call is really a liability decision.
Does an agent wallet stop prompt injection attacks on its own?
Not on its own, but it limits the consequences. The wallet cannot stop a model from being manipulated, yet because controls are enforced deterministically outside the model, an injected instruction can only spend within the caps, allowlists and session windows a human approved. Prompt injection becomes a bounded event rather than an open door to your funds.
