Card tokenization replaces a card’s primary account number (PAN) with a surrogate value, a token, that is useless to anyone who steals it. For a business, it does two jobs. It lowers the amount of sensitive card data your systems hold, and it makes mobile wallet and stored-card payments safer. It does not remove your compliance duties. This guide explains how tokenization works, what PCI DSS and PSD2 still require of you, and what to check with your card issuer if you operate in Lithuania or the wider EU.

DemivoltManage Business Cards with More ControlDemivolt offers virtual and physical business cards for expenses, alongside payment tools for businesses operating across borders.Explore Demivolt

TL;DR

A token stands in for the PAN. The real number stays in a protected vault with the issuer, processor or token service provider.
Tokenization can shrink your PCI DSS scope, but it does not eliminate the requirement to maintain PCI DSS compliance.
Adding a card to a digital wallet is a tokenization event. In the EU, the issuer must apply strong customer authentication (SCA) at that moment.
Systems that tokenize and de-tokenize stay in scope. Only segmented systems that handle tokens alone can fall out of it.
Before you choose a card programme, get the split of compliance responsibility between you, the issuer and any partner in writing.

What card tokenization is
How a token is created and used
What tokenization does for PCI DSS
Tokenization and PSD2: why SCA is part of it
The Lithuanian context
Where the real risk sits: people, not the token
A checklist for choosing a card programme
Our perspective: tokenization is a design decision, not a feature toggle
Cost clarity for the payments around your cards
How Demivolt can help
Common mistakes to avoid
FAQ
Sources

What card tokenization is

The PCI Security Standards Council describes tokenization as a process in which the PAN is replaced with a surrogate value called a token. The reverse step, de-tokenization, redeems a token for its original PAN. Only a tightly controlled system should be able to do that.

In plain terms: instead of storing 16 digits that anyone could use to pay, you store a reference. If an attacker copies your database, they get references that mean nothing outside the environment that issued them.

The word “tokenization” covers two situations that finance teams often mix up:

Merchant or platform tokenization. A company that accepts or stores cards (a subscription service, a marketplace, a travel agency) swaps the PAN for a token right after capture. Later charges use the token.
Network or wallet tokenization. A card is provisioned into Apple Pay, Google Pay or a similar wallet. The wallet holds a device-specific token, not the card number, and the real PAN is not passed to the merchant.

The second case matters if your company issues cards to employees. The first matters if you take card payments from customers. Many businesses face both.

How a token is created and used

The exact flow differs by provider, but the sequence is consistent:

Capture. The cardholder enters the card details, or an employee adds a company card to a wallet.
Verification. The issuer checks that the person is the rightful holder. In the EU this is where SCA applies.
Token issuance. A token service generates the token and links it to the PAN in a secured vault. For wallets, the token is also bound to the device.
Use. The token travels in payment messages. Merchants and intermediaries see the token, not the PAN.
Resolution. At authorization, the token is mapped back to the PAN inside the issuer or network environment, and the payment is approved or declined.

If a token is lost or a device is stolen, the issuer can suspend that single token without cancelling the physical card. That is a practical advantage for companies with many cardholders, remote staff and virtual cards used for subscriptions.

What tokenization does for PCI DSS

PCI DSS applies to any system that stores, processes or transmits cardholder data. Tokenization helps because it reduces how much of your environment touches the PAN. According to the PCI SSC, it can simplify PCI DSS validation by reducing the number of system components in scope.

The common mistake is to assume that once the PAN is removed from your database, the problem is solved. The PCI SSC guidance says otherwise: the tokenization and de-tokenization systems, and any system with access to them, remain in the cardholder data environment. Only adequately segmented systems that handle exclusively tokens, and never touch real cardholder data, can potentially be excluded.

Scope in practice

Component	Typical scope status
Token vault and de-tokenization service	In scope, full controls
Systems that can request de-tokenization	In scope
Application database holding only tokens, segmented from the above	Potentially out of scope
Analytics or CRM that receives tokens only	Potentially out of scope, if segmentation is proven
Payment page that captures the PAN before tokenizing	In scope, unless handled by a validated provider

This table is a simplification. Your assessor, or your provider’s attestation of compliance, decides the real boundary.

Controls that still apply

The systems that stay in scope need the same discipline as any cardholder data store: access control, monitoring, secure configuration and logging. Retired hardware matters too. If servers, laptops or drives ever held card data, their disposal belongs in your compliance plan, and a PCI-oriented data disposal playbook is a useful checklist for the IT asset side of that work.

Tokenization and PSD2: why SCA is part of it

For EU businesses, tokenization is also a regulatory matter. The EBA has confirmed that enrolling a payment card into a digital wallet creates a token and is a risky action. Under PSD2 Article 97(1)©, SCA applies to actions that carry a risk of fraud, and the EBA’s answer applies that to the tokenization stage.

Three practical consequences follow.

The issuer owns the check. The EBA clarified the application of SCA to the enrolment of a card to a digital wallet and to payments made with digitized cards. The issuer remains responsible for SCA, even when it relies on a wallet provider to carry out part of the verification.

A phone’s fingerprint or face unlock is not a substitute. Unlocking a device is not valid SCA for tokenization when the process is not under the issuer’s control. The issuer has to apply its own authentication elements during provisioning. Under PSD2, SCA means at least two of three categories: knowledge, possession and inherence.

Funded wallets add a second check. If a wallet is funded by a card, SCA is needed when that card is added and again when a payment is initiated, unless an exemption applies. The EBA’s Q&A on SCA for wallet solutions sets this out.

If you issue company cards, ask your issuer how it verifies the cardholder when a card is added to a wallet, which factors it uses, and what happens when an employee changes phones.

The Lithuanian context

Lithuania is a major hub for electronic money institutions and payment institutions, and the Bank of Lithuania supervises them. Two points are relevant for tokenization discussions.

First, regulatory boundaries are shifting. The Bank of Lithuania’s Payments Market Review describes a market moving toward more integrated models, where the line between EMIs and payment institutions blurs. As white-label and bundled services grow, several providers can sit in one payment chain. That makes clear contractual allocation of compliance responsibility more important. If you are comparing arrangements, a document such as a vendor trust and security page shows the kind of transparency to look for from any platform handling your funds and data, and a contract should then say who carries which obligation.

Second, crypto-related payments are being brought into the payment services framework. The Bank of Lithuania announced that from 2 March 2026 certain electronic money token transactions require an additional payment services authorization for crypto-asset service providers. This does not change how card tokenization works. It does matter if your business moves between cards, e-money and crypto-assets, because the licensing of each party in the chain should be checked.

The search results for this topic in Lithuanian are dominated by crypto and blockchain content. That is a different meaning of “token”. A payment token for a card is a security substitute for a card number. It is not a tradable asset.

Where the real risk sits: people, not the token

Tokenized wallets are a strong technical protection, but fraud adapts. ESET’s Lithuanian office has reported a rise in fraud cases linked to Apple Pay and Google Pay in Lithuania and says the main threat is not the technology itself. Criminals more often target people, persuading them to approve something.

For a company, that points to controls around people:

Train cardholders never to share one-time codes or approve a wallet enrolment they did not start.
Limit who can issue cards and set spending limits by role.
Review new wallet enrolments and unusual device changes.
Freeze or replace a card the same day a phone is lost.

A checklist for choosing a card programme

Use these questions with any issuer or programme manager, including us.

Who is the issuer of record, and who is licensed to do what? Confirm the authorization and the supervising authority.
How is SCA applied at wallet enrolment? The issuer should control it, not rely on device unlock.
Where is the PAN stored, and who can de-tokenize? Ask for the provider’s PCI DSS attestation.
Which parts of your own environment would be in scope? Get this in writing before integration.
Can individual cards and tokens be frozen separately? This reduces disruption after a loss.
How are controls split by user role? Finance leads, team members and auditors need different rights.
What does each payment cost? Transparent fees avoid surprises as volumes grow.
Who is liable when several providers share the chain? The contract should name the responsible party for each obligation.

Our perspective: tokenization is a design decision, not a feature toggle

We see the same pattern with growing companies. A finance team treats tokenization as a checkbox: the card is in the wallet, the PAN is hidden, the risk is gone. Then an audit or a partner questionnaire asks who verified the cardholder at enrolment, where de-tokenization happens and who is accountable if something fails. The answers should exist before launch.

Our view is built on how a regulated business account and card setup should work. Funds belong in dedicated accounts with segregated client money. Access should follow roles, so that the person who approves a payment is not always the person who issues a card. Fees should be published so a CFO can model costs. And where several parties are involved, such as a partner, an agency or a white-label arrangement, responsibilities should be written down rather than assumed.

Tokenization fits into that structure. It reduces exposure, but it works only when authentication, scoping and contracts are handled with the same care as the technology.

— dd

Cost clarity for the payments around your cards

Cards are rarely the only payment flow. Suppliers are paid by transfer, customers pay in by SEPA or SWIFT, and card spend is settled from an account. These are Demivolt’s published fees for those flows:

Item	Fee
Account opening	0
Account verification	0
Dedicated Client Manager	0
Monthly maintenance	0 per month
Internal transfers between Demivolt accounts	0
SEPA In	€0
SEPA Out	€0.40
SWIFT In	€25.00
SWIFT Out	€30.00
Account closure	0

You can model outgoing euro transfers with our SEPA fee calculator.

How Demivolt can help

Demivolt is a regulated European fintech platform that provides business banking and payment solutions. Companies can open business accounts with dedicated IBANs, send and receive SEPA and SWIFT payments, and set up virtual and physical Visa business cards through our card programmes. Multi-account structures and role-based user management let you separate teams, budgets and permissions.

If you are building a product that issues cards or accounts to your own customers, our Banking-as-a-Service offering and partner and white-label models are designed for that. Advisors can also refer clients through the reseller programme.

The details of wallet support, authentication flows and scope depend on the specific programme, so talk to us about your use case before you commit. To begin, contact us through demivolt.com.

Common mistakes to avoid

Treating tokens as a compliance exit. Tokenization changes your scope. It does not end your PCI DSS obligations.
Ignoring the de-tokenization path. Any system that can retrieve a PAN needs full controls.
Relying on phone biometrics for enrolment. The issuer must apply its own SCA at provisioning.
Skipping the contract. In multi-provider chains, unclear responsibility is a bigger risk than a missing feature.
Forgetting people. Social engineering targets approvals and codes, not the cryptography.
Confusing payment tokens with crypto tokens. They share a word and little else, and they fall under different rules.

FAQ

Is card tokenization the same as encryption?

No. Encryption transforms data with a key and can be reversed by anyone holding that key. A token is a substitute value with no mathematical link to the PAN, and it can be mapped back only through a secured lookup system. Both are used in payments, often together.

Does tokenization make my business PCI DSS compliant?

No. It can reduce the number of systems in scope, but the tokenization system itself and anything with access to it remain in scope. Your obligations depend on how you capture, store and process card data, so confirm your scope with your provider or a qualified assessor.

Do EU banks have to verify me when I add a card to Apple Pay or Google Pay?

Yes. According to the EBA, adding a card to a digital wallet creates a token, and the issuer must apply strong customer authentication at that stage. A device fingerprint or face unlock alone does not meet the requirement if the issuer does not control the process.

What should a Lithuanian company ask a card provider about tokenization?

Ask who the licensed issuer is, how SCA is applied at wallet enrolment, where the PAN is stored, which of your systems would be in PCI DSS scope, and how responsibilities are split between providers. Get the answers in the contract, not only in the sales material.

Card Tokenization for Businesses: How It Works and What It Covers