Stripe Shared Payment Tokens: Give a Seller Limited Payment Authority

A shopping assistant finds a replacement laptop charger. The buyer approves the merchant and final price, but the merchant still needs a usable payment credential. Sending the assistant’s full payment account is excessive; sending only a statement that the buyer approved something is insufficient. Stripe’s shared payment token, or SPT, occupies that middle layer.

Review boundary: official documentation checked November 1, 2026. This article describes credential scope and an illustrative order flow; we did not issue a token or charge a card.

Follow the grant, not just the token string

The agent integration guide describes collecting the seller’s Stripe profile and issuing a token that grants access to a customer’s payment method. The recipient matters: a token is not simply a universal card number that any merchant should accept.

In our charger example, bind the purchase decision to the selected seller, item, amount and currency before requesting the credential. If the agent switches merchants or changes the order, evaluate whether the existing grant still matches. A similar product title does not justify silently transferring the buyer’s approval to another seller.

Conceptual Stripe-processing path, not a live checkout. Credential issuance, payment processing and merchant order creation are separate events.

Limits belong in the payment contract

The seller guide documents amount, currency and expiration limits. It also now describes recurring SPTs with an explicit recurring interval. Therefore, “every SPT is one-use” is too broad; a one-time purchase and an ongoing charge permission need different explanations to the buyer.

For a replacement charger, an ongoing grant would be unnecessary. For a recurring service, show the interval and conditions instead of hiding them behind a generic “confirm” button. In both cases, the product should retain the approved order version. A ceiling does not explain why the charge was legitimate; it merely describes one constraint on the credential.

The seller sees a granted-token resource

Stripe’s API reference distinguishes the issued token from the recipient’s view-only granted-token resource. The latter exposes attributes and can be used with a PaymentIntent. Keep these roles distinct when deciding which system may create, inspect or use a grant.

The secret-bearing payment path should remain in the payment integration, not in a model’s conversation history. An assistant can reason about “approved, expired, declined” without being given every credential byte. Our recommendation is to expose a narrow tool that accepts an order identifier and returns a sanitized status, while the server performs the actual payment operation.

Event the user sees	What the application must establish
Purchase approved	The approved seller and final order are still current
Credential available	Scope, expiration and usage mode match that order
Payment attempted	The processor’s current payment state is known
Purchase completed	The merchant has an order and the required payment outcome

A timeout should not create a second purchase

If payment processing returns slowly, keep the original order and payment identifiers. Resolve their state before requesting another credential or creating another checkout. The buyer’s intent was to buy one charger, not to keep purchasing until the agent receives a convenient response.

Cancellation also crosses layers. Preventing future use of a credential does not itself cancel an existing merchant order or refund a processed payment. Support flows need to say which action was actually completed. A user should not see “refunded” merely because the assistant stopped trying to charge.

SPT, Link and commerce infrastructure are different subjects

SPT is the scoped-credential mechanism. Link Agent Wallet is a separate buyer-facing payment entry point, while Stripe’s commerce offering covers a broader merchant integration. An application may use these together, but they should not become three directory labels for the same thing.

Eligibility, supported countries, payment methods and API versions remain integration-specific. The reviewed examples use preview-version features; check the current SPT documentation before committing to a production path. This article supplies an architectural checklist, not assurance that a particular account can access every documented feature.