Category: Tokenization

Token Service Provider

Also known as:

Simply put

A Token Service Provider (TSP) is a company that replaces sensitive payment details, such as a card number, with a unique substitute value called a payment token. It generates, issues, and manages these tokens so that the original data does not need to be shared or handled directly during a transaction. TSPs play a central role in how tokens are created and maintained in digital payment systems.

Formal definition

A Token Service Provider is an entity responsible for generating, issuing, and managing EMV payment tokens that substitute for underlying cardholder data such as the primary account number (PAN). EMVCo maintains a TSP registration programme and assigns each registered TSP a three-digit TSP Code, while the PCI Security Standards Council publishes a Token Service Provider (TSP) Standard defining security requirements for TSPs that generate and issue EMV payment tokens. Tokenization performed by a TSP is distinct from encryption, truncation, masking, and hashing; its effect on PCI DSS scope depends on the specific implementation and validation rather than on the use of the term alone. Note that the security requirements applicable to TSPs are governed by the PCI TSP Standard and EMVCo specifications, which differ from PCI DSS and other PCI standards; consult the current published documents for authoritative requirements.

Why it matters

Token Service Providers sit at the center of modern payment tokenization because they generate, issue, and manage the payment tokens that substitute for underlying cardholder data such as the primary account number (PAN). When a token stands in for a PAN in a given payment flow, the sensitive value does not need to be shared or handled directly at that point in the transaction. This can reduce the exposure of cardholder data across the systems that touch a payment, though the actual effect on PCI DSS scope depends on the specific implementation and how it is validated, not on the use of the word 'tokenization' alone.

The role also matters because it is governed by dedicated frameworks rather than by PCI DSS in isolation. EMVCo maintains a TSP registration programme and assigns each registered TSP a three-digit TSP Code, while the PCI Security Standards Council publishes a Token Service Provider (TSP) Standard defining security requirements for TSPs that generate and issue EMV payment tokens. Because these requirements differ from PCI DSS and other PCI standards, organizations relying on or acting as a TSP should confirm obligations against the current published EMVCo specifications and PCI TSP Standard rather than assuming a single standard covers everything.

It is important not to overstate what tokenization by a TSP achieves. Tokenization is distinct from encryption, truncation, masking, and hashing, each of which transforms or reduces data differently. A TSP-issued token may help reduce the handling of sensitive values in certain flows, but it does not by itself address every fraud vector, and its scope-reducing effect must be established through implementation and validation rather than assumed from the label.

Who it's relevant to

Payment processors and acquirers

Organizations that route and settle transactions need to understand how TSP-issued payment tokens flow through their systems, including how tokens are generated, issued, and managed, and how a TSP is identified within the EMV ecosystem (for example, through the EMVCo-assigned three-digit TSP Code). They should determine whether their handling of tokens versus underlying PANs affects PCI DSS scope, confirming the outcome through implementation and validation rather than assuming scope reduction.

Issuers and card brands considering becoming their own TSP

Entities that may issue and manage payment tokens directly should review the EMVCo TSP registration programme and the security obligations set out in the PCI Token Service Provider (TSP) Standard. Because these requirements differ from PCI DSS and other PCI standards, they should consult the current published EMVCo specifications and PCI TSP Standard to establish the authoritative controls for generating and issuing EMV payment tokens.

Compliance officers and QSAs

Compliance and assessment professionals must distinguish the frameworks that govern TSPs from PCI DSS itself. Tokenization by a TSP is distinct from encryption, truncation, masking, and hashing, and its effect on PCI DSS scope depends on the specific implementation and validation. They should verify which standard applies to a given TSP function and confirm requirements against the current published documents rather than relying on the term alone.

Security engineers and integration teams

Teams designing or integrating tokenization into payment flows need clarity on where a TSP generates, issues, and manages tokens, and where underlying cardholder data such as the PAN is or is not present. They should design integrations so that any intended reduction in sensitive data handling can be demonstrated through validation, while recognizing that tokenization is one control among several and does not by itself address all fraud risks.

Inside TSP

Token vault or token generation process

The mechanism a TSP uses to generate payment tokens and, where applicable, maintain the mapping between a token and the underlying PAN. Depending on implementation, tokens may be vaulted (mapping stored) or generated using vaultless cryptographic methods; the approach affects how the token-to-PAN relationship is protected and how detokenization is controlled.

Token-to-PAN mapping and detokenization controls

Controls governing how a token can be exchanged back for the associated PAN, including which parties are authorized to request detokenization and under what conditions. Because the PAN is cardholder data, its storage and handling by the TSP remain subject to applicable controls.

Token domain restrictions and token attributes

Parameters that constrain where and how a token may be used, such as limiting a token to a specific merchant, channel, or transaction type. These restrictions are intended to reduce the usefulness of a token if it is exposed, though their effectiveness depends on correct configuration and enforcement.

Token provisioning and lifecycle management

Processes for issuing, activating, suspending, updating, and deactivating tokens over their lifecycle, including handling of card reissuance or expiration events. This lifecycle governance is a core function distinguishing token service from a one-time transformation.

Roles and integration points

The TSP interacts with parties such as card issuers, networks, acquirers, processors, and merchants or wallet providers. The specific responsibilities, and which applicable card brand and network rules apply, vary by program and region and should be confirmed against the governing agreements and standards.

Common questions

Answers to the questions practitioners most commonly ask about TSP.

Does a Token Service Provider encrypt cardholder data the same way as a P2PE solution?

No. Tokenization and encryption are distinct techniques with different properties, and a TSP is not the same as a P2PE solution. A TSP substitutes a payment token for a PAN and maintains the mapping (or means to derive it) so the token can be used within a defined domain, whereas encryption transforms data using a key that can reverse the process wherever the key is available. Truncation, masking, and hashing are yet other transformations. The effect any of these has on PCI DSS scope depends on the specific implementation and how it is validated, not on the label applied to it. P2PE specifically refers to solutions validated under the PCI P2PE standard, which is separate from tokenization performed by a TSP.

If I use a TSP, does that automatically remove my systems from PCI DSS scope?

Not automatically. Using a TSP may reduce the exposure of PAN in certain parts of an environment, but scope reduction is never conferred by the presence of tokenization alone. Whether tokens are considered out of scope, and to what extent, depends on how the tokenization is implemented, how tokens can be de-tokenized, where token-to-PAN mappings are held, and how the arrangement is assessed and validated. Any environment that can retrieve or influence the retrieval of the original PAN generally remains in scope. Confirm the actual scope impact through a formal assessment against the current published PCI DSS rather than assuming reduction.

When engaging a TSP, how should responsibilities be divided between our organization and the provider?

Responsibilities should be documented explicitly, typically through a responsibility matrix that identifies which party manages each relevant control, such as token generation, token vault security, de-tokenization access, key management for any underlying cryptography, and monitoring. A TSP acting as a third-party service provider may cover certain controls on your behalf, but residual responsibilities remain with your organization. Confirm which PCI DSS obligations the TSP addresses, obtain appropriate evidence of the provider's compliance status, and validate the boundaries of shared responsibility rather than assuming full coverage.

What should we verify about how a TSP handles de-tokenization and access to the token vault?

Verify who can request de-tokenization, under what conditions, and how those requests are authenticated, authorized, logged, and monitored. Because de-tokenization can reveal the original PAN, systems and personnel able to invoke it are typically treated as in scope. Review access controls to the token vault, segregation between token domains, and how the provider restricts token use to its intended domain. Any component that can reverse the token to a PAN should be evaluated for its scope and control implications during assessment.

How do we handle sensitive authentication data when working with a TSP?

Sensitive authentication data, which includes full track data, CAV2/CVC2/CVV2/CID, and PINs and PIN blocks, must not be stored after authorization, even in encrypted form. Tokenization by a TSP addresses the substitution of PAN and does not create an exception for storing sensitive authentication data. Confirm that neither your systems nor the TSP retain sensitive authentication data post-authorization, and treat cardholder data such as PAN under the defined storage controls that apply to it.

How do we confirm a TSP's compliance covers the specific requirements relevant to our environment?

Obtain documentation of the TSP's compliance status and the scope it covers, then map that scope to the controls you are relying on the provider to fulfill. Because PCI DSS requirement numbering and wording differ between versions, align the review against the current published standard rather than assuming a fixed requirement number. Distinguish PCI DSS obligations from those under separate standards where applicable, and retain evidence that supports the division of responsibilities for your own assessment.

Common misconceptions

Tokenization performed by a TSP is the same as encryption, so the two terms are interchangeable.

Tokenization and encryption transform data differently. Encryption uses cryptographic keys to produce reversible ciphertext, while tokenization substitutes a surrogate value that may be generated with or without reversible cryptography. Their effect on PCI DSS scope depends on the specific implementation and validation, not on the label alone; using a TSP does not automatically remove an environment from scope.

If a merchant uses a TSP and only handles tokens, sensitive authentication data storage rules no longer matter.

Tokenization does not change the rule that sensitive authentication data, such as full track data, card verification values, and PINs or PIN blocks, must not be stored after authorization even when encrypted. A TSP addresses the handling of the PAN and related cardholder data; it does not authorize retention of sensitive authentication data.

A single PCI standard governs everything a TSP does.

PCI DSS is distinct from related standards such as PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS. Which requirements apply to a TSP depends on its functions and the applicable card brand and network token program rules. Requirement wording and numbering also differ between PCI DSS versions, so obligations should be confirmed against the current published standard and program rules.

Best practices

Confirm which parties are authorized to request detokenization and restrict the token-to-PAN mapping to the minimum roles and systems necessary, treating any recovered PAN as cardholder data subject to applicable controls.

Apply and verify token domain restrictions and attributes so tokens are limited to specific merchants, channels, or transaction types where the program supports it, and validate that these constraints are actually enforced rather than assumed.

Do not rely on a TSP relationship to permit retention of sensitive authentication data; ensure full track data, card verification values, and PINs or PIN blocks are not stored after authorization.

Do not assume tokenization automatically removes systems from PCI DSS scope; assess and document scope based on the specific implementation and validate it rather than relying on the tokenization label.

Establish clear token lifecycle procedures covering provisioning, suspension, update, and deactivation, including handling of card reissuance and expiration events.

Confirm the applicable standards and card brand and network program rules that govern the TSP's functions in your region, and verify requirements against the current published versions rather than assuming fixed requirement numbers or dates.