stripe link connects a user’s wallet through oauth and issues a one-use payment credential for an approved purchase. KERNEL stores that credential encrypted, gives your agent non-secret aliases, substitutes the credential at browser egress, and then consumes the card item.
stripe link is the credential provider, not the merchant’s payment processor. at
the browser form layer, it works with any web checkout that accepts standard
card details, and the merchant’s processor doesn’t need to be stripe. end-to-end
handoff also requires the outgoing request to match a native processor
adapter. for
example, you can use a stripe link credential in a Shopify checkout.
Before you start
create a project-scoped client and vault. the examples below use these kernel and vault variables.
Lifecycle
- create a
wallet item with the link oauth specification.
- open the returned
link_oauth action for the user and wait for the wallet to become connected.
- request the advertised
payment_methods expansion and let the user choose an eligible method.
- create a
card item with the purchase details.
- retrieve the card, verify that it advertises
authorize, and perform that operation after explicit user approval.
- complete the returned
spend_approval or push_approval action and wait for state.status to become ready.
- use
state.aliases in an attached browser. the first native handoff changes the item to consumed.
Connect a wallet
before showing a stripe link connection option, list the vault’s items. if a
link wallet already exists in any state, reuse it and do not let the user add
another. show its existing action or status instead. the api makes item keys
unique but does not currently enforce one wallet per provider, so the ui must
enforce a maximum of one link wallet per vault.
the examples use presentProviderAction, an application-owned function that
publishes the action to an authenticated session for the end user who owns the
vault. bind the action to that user, vault, and item; apply a short application
ttl capped by wallet.expires_at when present; and stop serving it when the
action changes or disappears. derive authenticatedUser from the server-side
session, not a request field. do not log the url or put it in model context.
open collection and approval urls in a trusted user-facing surface. don’t give
them to the agent or print full wallet responses into model context. run cli
--open only from a trusted, human-operated terminal because the command
output can contain the action url.
Select a payment method
request payment_methods only when available_expansions advertises it. the expansion comes from link at request time and is not persisted in the vault item.
show the returned methods in a trusted user-facing surface, let the user choose one, and set its id as LINK_PAYMENT_METHOD_ID. missing capability metadata means eligibility is unknown. only eligible: false is an explicit negative result.
Create and authorize a card item
amount uses minor currency units, so 2306 means 23.06 usd. link accepts values from 1 to 500000. context must contain at least 100 characters. card creation is live-only, and spec.test is not supported.
merchant_url supplies provider context. KERNEL derives its registrable domain into state.domains when authorization starts, but state.domains is metadata rather than an enforced browser-origin allowlist.
Use the aliases
after the user completes the approval action, retrieve the card with wait: 60 until it becomes ready. pass state.aliases to the browser agent payments guide.
the first recognized processor request that contains the aliases consumes the
item and clears its encrypted card value. consumed means the credential was
substituted, not that the processor accepted the payment or the merchant created
an order.
don’t repeat authorize or create a replacement item to retry an unknown purchase. inspect item events and the merchant’s order state first.