customerId you supply when creating the SDK session on your server.
How it works
1
First visit — vault the card
Pass The charge response includes a
customerId to POST /sdk/session when the shopper reaches checkout. When they complete payment, include card.nonceData.tokenize: true and shopper.id in your server-side charge request. Therius vaults the card under that shopper ID.token you can store against the shopper in your own database for reference.2
Returning visit — retrieve saved cards
Pass the same Each saved method is returned as:A raw PAN is never returned to the browser.
customerId to POST /sdk/session. The Checkout Widget automatically shows the shopper’s saved cards. To retrieve them programmatically, call sdk.getSavedMethods():3
Charge the saved card
Pass the token to
sdk.authorizeToken() with the payment amount. No card re-entry is required.Token scope and security
- Saved cards are returned as
{ brand, last4, expiryMonth, expiryYear, token }— never a usable PAN. Your UI can display card details safely. - Cards are scoped to the merchant — a token created under one merchant account cannot be used at another.
- Vaulted-methods retrieval is resolved purely from the session JWT — the browser cannot enumerate a different shopper’s cards by supplying a different ID. The scope is enforced server-side by Therius.
Using saved cards with the Checkout Widget
When acustomerId is set in the session, the Checkout Widget handles saved-card display and selection automatically. Pass onSavedMethodSelected to receive the token when a returning shopper picks a card:
The
GET /sdk/vaulted-methods endpoint that backs saved-card retrieval is also accessible directly if you prefer to call it from your own front-end code. The session JWT in the Authorization header scopes results to the session’s shopper automatically.
