The problem SPT solves
When an AI agent — one built into ChatGPT, say, or a voice assistant — makes a purchase on a user’s
behalf, one question decides everything: how do you give the agent the ability to pay without giving
it real payment credentials?
The classic options are both bad. Either the agent stores card data, which is a security risk, or
the user is sent back to a payment form by hand, which destroys the autonomy. The Shared Payment
Token is the compromise: the user authorises a token once, with defined limits, and the agent uses
it for one specific transaction.
How the mechanism works
1. The user authorises the AI application in Stripe
2. Stripe issues an SPT with constraints (amount, validity, category)
3. The AI agent passes the SPT to the merchant through ACP
4. The merchant initiates the charge through the Stripe API
5. Neither the agent nor the merchant ever sees the card data
The token is single-use: once spent, it is void. If the transaction does not happen inside the
validity window, the token expires on its own.
SPT and adjacent concepts
| Concept | Who controls it | Scope |
|---|---|---|
| SPT | Stripe | One transaction between agent and merchant |
| Payment Mandate | The user or the AI application | Pre-set limits across all of the agent’s operations |
| Delegated Payments Spec | Any PSP | The standard for non-Stripe providers |
Status and adoption
As of 2025 the SPT is a relatively new primitive, introduced by Stripe together with Anthropic and
OpenAI as part of pushing the ACP protocol forward. Commercial adoption outside those companies’
ecosystems is still limited, and in markets where local payment service providers have not announced
ACP support the standard has little practical relevance yet. The broader idea of delegated payments,
however, will grow as agentic commerce spreads.