How Agents Actually Pay
The mechanical heart of Stripe's agentic launch is the Shared Payment Token (SPT) and its surrounding choreography. A consumer first grants an agent access to their Link wallet via a standard OAuth flow, the same pattern used for granting third-party apps access to a Google or GitHub account. Once authorized, the agent is no longer holding card numbers; it is holding a scoped credential. For each task the agent kicks off, Stripe issues either a one-time-use virtual card or a Shared Payment Token bound to a specific seller, time window, and amount. The agent presents that token at checkout, the merchant submits it through the normal Stripe API, and the payment shows up in the Stripe Dashboard like any other transaction, settling in the business's existing balance and default currency.
This design solves the credential exposure problem that has haunted every prior attempt at machine payments. Real card details never touch the agent's runtime; if a model is jailbroken or a prompt-injected webpage tries to coerce a purchase, the worst case is a token whose blast radius is already limited by issuance scope. Issuing for agents extends the same idea to platform builders: developers can programmatically generate single-use virtual cards on demand, so an autonomous workflow can buy a domain, top up an API quota, or pay a vendor without anyone in the loop. On the merchant side, MPP transactions ride the same rails as cards, Klarna, and Affirm, so accepting agent traffic does not require a parallel ledger. The architectural through-line is that Stripe is treating the agent as just another authenticated client, with cryptographic scoping doing the work that human attention used to do at checkout.




