Skip to content

CONCEPT Cited by 2 sources

Shared Payment Token (SPT)

Definition

A Shared Payment Token (SPT) is a payment primitive built for agentic commerce that lets an AI agent initiate a payment with a human buyer's permission and preferred payment method, without exposing the buyer's raw credentials to the agent.

Introduced by Stripe and canonicalised in the 2026-03-12 "10 things we learned building for the first generation of agentic commerce" retrospective, where it is positioned as the load-bearing primitive that makes the entire agentic-commerce stack workable — "this token layer is where Stripe adds particular value."

The three-party structure

Three roles separated by the token:

  1. Buyer — grants the agent permission, chooses the payment method, and identifies to Stripe out-of-band (e.g. via Link). Credentials are vaulted inside Stripe — see concepts/token-vault.
  2. Agent — holds an SPT scoped to the buyer's intent (a specific cart, specific merchant, specific amount window). Initiates the payment; the token is the credential it passes to the seller.
  3. Seller — receives the SPT from the agent, uses it to authorise the payment with Stripe. Never sees the buyer's raw payment credential.

How it differs from traditional tokenisation

Traditional card tokenisation (network tokens, vaulted PANs) scopes tokens to "this card, used by this merchant." SPTs instead scope to "this cart, initiated by this agent, on this buyer's behalf." The novel axis is the agent as a first-class initiator distinct from both seller and buyer — classical token-vault systems assume a human buyer is the initiator.

The ACP spec formalises this via its scoped-tokens RFC (rfc.seller_backed_payment_handler).

Where it composes on this wiki

  • concepts/token-vault — SPT is a token-vault instance with the initiator-role expanded. Classical token vaults (Visa TRID, Apple Pay DPAN) don't model an agent initiator; SPTs explicitly do.
  • Link — the mechanism by which buyer credentials are pre-vaulted into Stripe so an SPT can reference them without the agent ever seeing card details. Returning Link customers get a faster SPT issuance path.
  • Radar — fraud scoring reads SPT-carried metadata so it can scrutinise the transaction "even when authorization happens off-Stripe" (via Mastercard Agent Pay or Visa Intelligent Commerce network- level settlement).
  • ACP and Google UCP — standards layer that specifies the wire shape of an SPT being exchanged between agent and seller.

Payment-method coverage

Per the 2026-03-12 post, SPTs support (or are being extended to support) Mastercard Agent Pay, Visa Intelligent Commerce (per the 2026-03-03 coverage announcement not separately ingested), and BNPL instruments (Affirm, Klarna). The token vault internals — wire format, lifetime, revocation, the exact scope fields — are not disclosed in the 2026-03-12 post; the reference is docs.stripe.com/agentic-commerce/concepts/shared-payment-tokens.

Seen in

  • sources/2026-04-29-stripe-giving-agents-the-ability-to-pay — canonicalises a new issuance path for SPTs: the Link wallet for agents mints an SPT (or a sibling one-time-use virtual card) in response to an approved consumer spend request. This is distinct from SPT issuance via the ACP checkout path (the 2026-03-12 canonicalisation) — the wallet shape is consumer-account-anchored + per-spend- human-approval-gated rather than seller-ACP-round-trip- anchored. The agent doesn't even choose SPT vs card; the wallet picks based on the merchant. Launch post framing: "the ability to get a one-time-use card or a Shared Payment Token (SPT), backed by the cards and bank accounts already in your wallet." Extends SPT's role-topology from three-party (buyer / agent / seller) to four-party (wallet / buyer / agent / seller), with the wallet now authoritative for issuance + scope.
  • sources/2026-03-12-stripe-10-things-we-learned-building-for-the-first-generation-of-agentic-commerce — canonical Stripe framing of SPT as the agent-initiated payment primitive.
Last updated · 542 distilled / 1,571 read