> 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/tokenization.md). # Tokenization Securely store and reuse payment credentials without handling sensitive card data. Tokenization is the process of replacing sensitive payment data, such as a Primary Account Number (PAN), with a unique, non-sensitive value called a token. The token can be safely stored and reused for future payments without exposing the original card details. The SEB Ecommerce Payment Gateway creates and manages tokens on your behalf. Instead of storing card numbers, your systems store only a gateway token reference – an identifier that you include in subsequent payment requests. All sensitive card data remains within the gateway’s PCI DSS compliant environment and is never exposed to your systems or personnel. Tokenization is the foundation for the following gateway features: * [Stored Credentials](/payment-methods/cards/stored-credentials.md) (Card-on-File) * [One-Click Payments](/features/one-click-payments.md) * [Recurring Payments](/features/recurring-payments-and-subscriptions.md) (Subscriptions) * [Merchant-Initiated Transactions ](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md)(MIT) {% hint style="info" %} A payment token has no intrinsic value outside the Payment Gateway and cannot be used to reconstruct the original card details. {% endhint %} ### Capability Summary
CapabilitySupport
Payment MethodsPayment Cards (Visa, Mastercard)
Internal (Gateway) TokenizationSupported
Network TokenizationVisa Token Management Service (TMS), Mastercard Secure Card on File (SCOF)
Token VaultPCI DSS compliant, operated by the Payment Gateway
Customer-Initiated Transactions (CIT)Supported
Merchant-Initiated Transactions (MIT)Supported, including EMV® 3DS Requestor-Initiated (3RI) authentication where applicable
Token Lifecycle ManagementAutomatic updates from card schemes (network tokens)
Token Status NotificationsCallback notifications (webhooks)
Integration OptionsMerchant API, Hosted Checkout
Sandbox TestingAvailable
Availability of individual capabilities depends on your merchant agreement, enabled services, and acquiring configuration. ### How Tokenization Works A token is created during an initial Customer-Initiated Transaction (CIT) in which the customer explicitly agrees that their payment credentials may be stored for future use. The typical flow is: 1. Initial payment (CIT). The customer completes a payment and consents to storing their payment credentials. 2. Token creation. The gateway securely stores the payment credentials in its PCI DSS compliant token vault and generates a token. Depending on your configuration, a scheme-issued network token may also be provisioned. 3. Token reference returned. The token ID is returned to you in the payment response, together with the other payment details. Store this reference in your systems against the customer profile. 4. Subsequent payments. For future payments, include the token ID in the payment request instead of card data. The gateway resolves the token and processes the transaction through the standard authorization, capture, reversal, and refund flows. Subsequent payments can be either Customer-Initiated Transactions (for example, one-click checkout while the customer is present) or Merchant-Initiated Transactions (for example, a monthly subscription charge processed without the customer’s active participation). {% hint style="warning" %} The card security code (CVV/CVC) is never stored, even when tokenization is used. This is a PCI DSS requirement that applies to all merchants and service providers. {% endhint %} ### Token Types The Payment Gateway supports two complementary tokenization models. Depending on your acquiring setup, scheme participation, and merchant configuration, they may operate independently or in combination. In both models you interact with a single gateway token reference – the gateway manages the underlying credentials transparently. #### Internal (Gateway) Tokens With internal tokenization, sensitive cardholder data is replaced with a secure, gateway-generated token within the Payment Gateway’s PCI DSS compliant environment. Internal tokens are used exclusively within the gateway for transaction processing and credential reuse. Internal tokenization: * Removes raw card data from your systems, reducing your PCI DSS compliance scope. * Enables one-click payments, recurring transactions, and subscription services. * Minimizes the risk of cardholder data exposure. #### Network Tokens With network tokenization, the original PAN is replaced with a network token issued and managed by the card scheme itself. The gateway integrates with the card scheme tokenization services to provision, store, and use network tokens for transaction processing: * Visa Token Management Service (TMS) for Visa card credentials. * Mastercard Secure Card on File (SCOF) and related Mastercard token lifecycle services (including legacy MDES-based integrations) for Mastercard card credentials. Network tokens follow the EMV® Payment Tokenisation Specification and are bound to a specific merchant context, which makes them unusable if intercepted. Each transaction is additionally protected by scheme-level validation. Beyond security, network tokens provide practical business benefits: * Automatic credential updates. When the underlying card is reissued, replaced, or its expiry date changes, the card scheme updates the token automatically. Stored credentials keep working without asking the customer to re-enter card details – particularly valuable for subscriptions and recurring billing. * Higher approval rates. Issuers generally approve tokenized transactions more often than PAN-based transactions, because the scheme pre-validates each token before the authorization reaches the issuer. Card schemes report measurably higher approval rates for tokenized card-not-present transactions. * Reduced payment friction. Fewer declines caused by expired or replaced cards mean fewer interrupted subscriptions and less involuntary customer churn. #### Comparison
AspectInternal (Gateway) TokenNetwork Token
Issued bySEB Ecommerce Payment GatewayCard scheme (Visa, Mastercard)
ReplacesPAN within the gateway environmentPAN across the payment network
Lifecycle managed byPayment GatewayCard scheme; the gateway processes lifecycle events and updates its records
Automatic card updatesNot applicableYes (reissuance, expiry updates, replacement)
Approval rate uplift–Yes, reported by card schemes for tokenized transactions
PCI DSS scope reductionYesYes
Merchant integrationGateway token referenceGateway token reference (network token is transparent to the merchant)
{% hint style="info" %} You never handle network tokens directly. When a network token is provisioned, the gateway stores it securely in its token vault, links it to the relevant merchant or customer profile, and provides you with a gateway token reference for subsequent CIT and MIT payments. {% endhint %} ### Token Lifecycle Tokens are long-lived credentials. Their status determines whether they can be used for payment processing. For network tokens, lifecycle events are governed by the card schemes and their tokenization services. When the gateway receives a lifecycle notification from the card scheme, it updates the corresponding token records in the token vault and adjusts the token status for transaction processing. These updates occur transparently – your integration and stored token references continue to work without changes. #### Lifecycle Events
EventDescriptionImpact on the Merchant
ActivationThe token has been provisioned and is ready for use.The token reference can be used for payments.
UpdateToken metadata has changed, for example a new expiry date after card reissuance.None – the update is applied automatically.
ReplacementThe underlying card was replaced (for example, lost or stolen) and the scheme mapped the token to the new card.None – the existing token reference remains valid.
SuspensionThe token has been temporarily suspended, for example at the issuer’s or cardholder’s request.Payments with the token are declined until it is reactivated.
Deactivation/DeletionThe token has been permanently deactivated.The token reference can no longer be used. Ask the customer to provide a payment method again.
#### Token Status Notifications The gateway notifies your systems about token status changes via callback notifications (webhooks). Use these notifications to keep the payment methods stored against your customer profiles up to date – for example, to hide a deactivated card from the customer’s saved payment methods, or to prompt the customer to add a new card before the next subscription charge. ### Use Cases #### One-Click Payments A returning customer selects a saved payment method and confirms the purchase without re-entering card details. The payment is processed as a Customer-Initiated Transaction using the stored token and may require EMV® 3-D Secure authentication depending on regulatory requirements and the issuer’s risk assessment. #### Recurring Payments and Subscriptions After the initial CIT in which the customer consents to recurring billing, you charge the stored token at the agreed intervals as Merchant-Initiated Transactions. Where applicable, MITs may use EMV® 3DS Requestor-Initiated (3RI) authentication and may qualify for Strong Customer Authentication (SCA) exemptions, subject to applicable regulations and the issuer’s authorization decision. #### Unscheduled Merchant-Initiated Transactions Usage-based billing, delayed charges, top-ups, or account fees are processed against the stored token when the triggering event occurs, without the customer being present. Each MIT must reference the original customer consent established during the initial CIT. Note: Tokenization and Merchant-Initiated Transactions are supported for card payments. For details on CIT/MIT classification, customer consent requirements, and the Visa and Mastercard Stored Credential Framework, see Stored Credentials. ### Security and Compliance Tokenization reduces the handling of sensitive payment data and enhances the security of payment processing: * PCI DSS compliant token vault. All card credentials are stored in the gateway’s PCI DSS compliant token vault. Raw card data is not exposed to merchants. * Reduced PCI DSS scope. Because your systems store only token references, tokenization can significantly reduce your PCI DSS compliance scope. The applicable Self-Assessment Questionnaire (SAQ) is determined by your complete payment environment and implementation. * No intrinsic value. A token cannot be used to reconstruct the original card details and has no value outside the Payment Gateway. * Scheme-level protection. Network tokens are issued and validated by the card schemes in accordance with the EMV® Payment Tokenisation Specification. * No CVV storage. The card security code (CVV/CVC) is never stored after authorization, in line with PCI DSS requirements. Merchants should never store cardholder data unless their PCI DSS compliance scope explicitly permits it. Use tokenization instead of storing payment card numbers. ### Tokenization and Digital Wallets Digital wallets such as Apple Pay and Google Pay use their own provider-specific tokenization mechanisms. Card details are not entered manually by the customer but are retrieved securely from the selected wallet and provided to the gateway in the form of a payment token. These wallet tokens are governed by the wallet provider and the applicable card scheme rules and are distinct from the gateway and network tokens described on this page. For details, see Apple Pay and Google Pay in the Wallets section. ### Merchant Requirements Before using tokenization, ensure that: * Tokenization and Stored Credentials are included in your merchant agreement and enabled for your merchant account. * Your checkout obtains the customer’s explicit consent before payment credentials are stored. The consent should clearly describe the purpose of storing the credentials, the payment frequency and amount or billing model (where applicable), and the cancellation process. * Your systems store the token ID returned in the payment response and reference it in subsequent payment requests. * Your integration processes token status notifications (webhooks) and keeps saved payment methods up to date. Availability of network tokenization additionally depends on card scheme program enrollment, approvals, and acquiring configuration. ### Testing Complete all development and validation in the Sandbox environment before processing live transactions. Before requesting Production activation, verify: * Token creation during an initial Customer-Initiated Transaction, including the customer consent step. * The token ID is received in the payment response and stored correctly in your systems. * One-click payments using a stored token (CIT). * Recurring payments using a stored token (MIT). * Declined payment scenarios, including payments with a suspended or deactivated token. * Token status notifications (webhooks) and the resulting updates in your systems. * Refund processing for token-based payments. ### Merchant Best Practices We recommend that merchants: * Use tokenization instead of storing payment card numbers. * Obtain explicit customer consent before storing payment credentials, and retain evidence of the consent. * Clearly communicate recurring billing terms and notify customers before recurring charges where required by applicable regulations or card scheme rules. * Initiate Merchant-Initiated Transactions only after a valid Customer-Initiated Transaction. * Subscribe to token status notifications and handle expired, replaced, or deactivated tokens appropriately. * Allow customers to view, update, and delete their saved payment methods. * Maintain PCI DSS compliance appropriate to your payment environment. ### Frequently Asked Questions #### Does the token change when the customer’s card is reissued? No. For network tokens, the card scheme maps the existing token to the new card automatically, and the gateway updates its records transparently. Your stored token reference remains valid, and recurring payments continue without interruption. #### Can I use one token across multiple shops? Tokens are linked to the merchant or customer profile under which they were created. Whether a token can be shared across several of your shops depends on your merchant configuration. Contact your SEB representative for details. #### Is the CVV stored with the token? No. The card security code must never be stored after authorization, even when tokenization is used. Payments with stored credentials are processed without the CVV, in accordance with card scheme rules for stored credential transactions. #### Do tokenized payments still require 3-D Secure? Customer-Initiated Transactions with a stored token may require EMV® 3-D Secure authentication depending on regulatory requirements and the issuer’s risk assessment. Merchant-Initiated Transactions are out of SCA scope and may use 3DS Requestor-Initiated (3RI) authentication where applicable; the final authorization decision always remains with the issuer. #### What happens if a token is deactivated? Payments referencing the token are declined. You will receive a token status notification so that you can prompt the customer to provide a new payment method. ### Related Documentation Continue with the following topics: * [Stored Credentials](/payment-methods/cards/stored-credentials.md) * [Customer-Initiated Transactions (CIT)](/payment-methods/cards/stored-credentials/customer-initiated-transactions-cit.md) * [Merchant-Initiated Transactions (MIT)](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) * [One-Click Payments](/payment-methods/cards/stored-credentials/one-click-payments.md) * [Recurring Payments & Subscriptions](/features/recurring-payments-and-subscriptions.md) * [EMV® 3-D Secure (EMV 3DS)](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) * [Callback Notifications](/integration/merchant-api/webhooks.md) * [Testing](/payment-methods/cards/testing.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/tokenization.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.