OAuth + SPT: How an Agent Pays Without Ever Holding Your Card
The technical heart of Link is a deliberately layered handoff that keeps raw payment credentials inside Stripe and out of the model's context window. A user first connects payment methods to Link, then grants their agent access through a standard OAuth flow — the same pattern that lets a third-party app post to a user's social account without learning the password. From there the agent does not freely charge anything; it builds a structured spend request, attaches context (what it wants to buy, why, and on whose behalf), and waits for the user to approve. Only after approval does Stripe issue either a one-time-use virtual card or a Shared Payment Token (SPT) backed by the user's existing cards and banks. Stripe is explicit that "the agent never gets access to your raw payment credentials."
This is meaningfully different from giving an agent a card number in a prompt. The SPT is scoped to a specific seller and constrained parameters — Stripe's own developer videos describe it as a primitive that "securely passes your card to sellers without exposing details," with the network performing identity and risk checks before authorization. Sellers integrate with what Stripe calls a one-line code change. The result is an architecture where the credential, the delegation, and the authorization each live in different places, and a compromised agent leaks at most a scoped token rather than a reusable card.



