> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/payment-methods/cards/stored-credentials.md). # Stored Credentials Save a customer’s card once – with their consent – and use it for one-click checkout, subscriptions, and merchant-initiated charges. This page is your map of how the pieces fit together. Stored Credentials enable merchants to securely save customer payment credentials for future use, in line with the Visa and Mastercard Stored Credential Framework. Instead of asking the customer to re-enter their card for every purchase, you store a token – created by the gateway with the customer’s explicit consent – and reference it in later payments. Under the hood, stored credentials are built on Tokenization: raw card data never reaches your systems, and the gateway’s PCI DSS compliant token vault holds the credentials. On top of that foundation, the Stored Credential Framework defines who initiates each payment – the customer or you – and what rules apply in each case. {% hint style="info" %} Stored credentials are supported for payment methods that allow credential storage and tokenization – currently, card payments (including cards used through Apple Pay and Google Pay, subject to your configuration). Pay by Bank uses its own account-reference model – see One-Click Payments with Pay by Bank. {% endhint %} ### How It Fits Together Every stored-credential relationship follows the same shape: 1. It starts with an initial Customer-Initiated Transaction (CIT). The customer pays while actively present, explicitly agrees that their credentials may be stored, and completes any required authentication. The gateway creates a token and returns the token ID to you. This is the foundation – nothing else is possible without it. 2. The customer can use the saved card while present. The returning customer selects their saved card and confirms the purchase – a subsequent CIT, better known as a one-click payment. 3. Or you can charge it without the customer present. Your systems charge the stored token as a Merchant-Initiated Transaction (MIT) – for subscriptions, usage-based billing, or agreed follow-up charges – always within the scope of the consent the customer gave. ### What You Can Build With It

Use Case	How It Works	Transaction Type	Read
One-click checkout	Returning customer picks a saved card and confirms – no card entry	Subsequent CIT	One-Click Payments; CIT
Subscriptions and memberships	Fixed charges at intervals your systems initiate	MIT (recurring)	MIT
Usage-based and metered billing	Variable charges when the triggering event occurs	MIT (unscheduled)	MIT
Installments	A purchase amount split into scheduled parts agreed with the customer	MIT	MIT
Delayed or follow-up charges	Additional agreed amounts after the original purchase	MIT	MIT
Saved cards management	Customers view, update, and delete their stored payment methods	–	Tokenization (lifecycle, notifications)

### The Rules at a Glance * Consent comes first. The customer must explicitly agree to storing their credentials during the initial CIT – an active choice, with the purpose, billing model, and cancellation process clearly described. Retain evidence of the consent; every MIT references it. Full requirements: Customer-Initiated Transactions (CIT). * MIT only after a successful initial CIT. A declined or abandoned initial CIT establishes nothing – no stored credential may be charged. * Use the correct transaction type. Customer present and confirming → CIT; charge triggered by your systems → MIT. Correct classification affects authentication, approval rates, liability, and scheme compliance. * The token ID is your key. The initial payment response returns the token ID – store it against the customer profile and reference it in every subsequent CIT and MIT. * Tokens have a lifecycle. Subscribe to token status notifications and react when a token is suspended, deactivated, or updated – see Tokenization. * Authentication is built in. SCA applies to the initial CIT; subsequent CITs may qualify for exemptions; MITs use 3RI where applicable. The gateway handles this – see EMV® 3-D Secure. ### In This Section

Page	Text
Customer-Initiated Transactions (CIT)	How the stored-credential relationship is established: the initial payment, consent requirements, one-click flow, authentication and SCA.
Merchant-Initiated Transactions (MIT)	How to charge without the customer present: the two-step flow, use cases, division of responsibilities (scheduling is yours), declines and retries.
One-Click Payments	The subsequent-CIT experience in detail: presenting saved cards, checkout flow, authentication.

### Where to Start 1. Establish the credential. Read Customer-Initiated Transactions (CIT) and implement the initial payment with the consent step – verify you receive and store the token ID. 2. Add the reuse scenario you need. Add one-click checkout for returning customers (subsequent CIT), or merchant-initiated charging for subscriptions and billing (MIT) – or both. 3. Close the loop. Process token status notifications, let customers manage their saved cards, and test the full journey in the Sandbox – including declined initial payments and deactivated tokens. ### Related Documentation * [Customer-Initiated Transactions](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md) (CIT) * [Merchant-Initiated Transactions](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) (MIT) * [One-Click Payments](/payment-methods/cards/stored-credentials/one-click-payments.md) * [Tokenization](/payment-methods/cards/tokenization.md) * [EMV® 3-D Secure](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) (EMV 3DS) * [Payment Statuses](/payment-methods/cards/payment-statuses.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.ecommerce.seb.ee/payment-methods/cards/stored-credentials.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.