Category: Tokenization

Token Provisioning

Also known as: Payment Token Provisioning, Network Token Provisioning

Simply put

Token provisioning is the process of creating a payment token that stands in for an actual card's primary account number (PAN) and delivering it to where it will be used, such as a digital wallet or a merchant's stored-credential system. Instead of a merchant or wallet holding the real card number, it holds a surrogate value that represents that card for a specific use. This is intended to help reduce exposure of the underlying card data during storage and transactions.

Formal definition

Token provisioning is the lifecycle step in which a token service provider generates a payment token as a surrogate value for an underlying PAN and incorporates it into a target domain, such as a digital wallet, device, or merchant credential-on-file store. In network tokenization, provisioning is typically triggered at enrollment or checkout when card details are submitted, and it involves the requesting party, the token service, and the issuer, which may participate in credential management and authorization of token issuance (for example, via services such as Visa Token Service). Provisioning is distinct from the token's later use in transactions and from the cryptographic mechanisms that bind a token to a specific device, merchant, or channel. Note that tokenization is not the same as encryption, truncation, masking, or hashing, and that whether a given provisioning implementation reduces PCI DSS scope depends on the specific architecture and its validation, not on the term alone; confirm applicable requirements against the current published standard.

Why it matters

Token provisioning matters because it determines where and how a surrogate value, rather than the actual primary account number (PAN), comes to reside in a digital wallet, on a device, or in a merchant's credential-on-file store. By substituting a token for the underlying card data at the point of creation, provisioning is intended to help reduce exposure of the real PAN during storage and subsequent transactions. This is significant for merchants and wallet operators that would otherwise hold sensitive cardholder data across many stored credentials.

Proper provisioning also establishes the relationships among the requesting party, the token service provider, and the issuer, which may participate in credential management and authorization of token issuance. Because the issuer can be involved at enrollment, provisioning is the stage where trust in the token is established before it is ever used in a transaction. Weaknesses at this stage, such as inadequate verification of the requesting party or the card details submitted, can undermine the value of tokenization regardless of how the token later behaves.

It is important not to overstate what provisioning achieves. Tokenization is not the same as encryption, truncation, masking, or hashing, and whether a given provisioning implementation reduces PCI DSS scope depends on the specific architecture and its validation, not on the use of the term alone. Organizations should confirm applicable requirements against the current published PCI DSS standard rather than assuming that provisioning tokens automatically removes systems from scope.

Who it's relevant to

Card Issuers

Issuers may participate in credential management and the authorization of token issuance during provisioning. Issuer-facing capabilities, such as the Visa Token Service Provisioning and Credential Management APIs, are intended to provide flexible and scalable ways to help securely issue tokens for their cardholders' PANs.

Merchants with Stored Credentials

Merchants operating credential-on-file systems are a common target domain for provisioned tokens, holding a surrogate value rather than the real card number for a specific use. They should note that whether provisioning reduces their PCI DSS scope depends on the specific architecture and its validation, confirmed against the current published standard, not on the tokenization label alone.

Digital Wallet and Device Providers

Wallets and devices are frequent target domains where a token is incorporated during provisioning. For these parties, provisioning is the step that establishes the surrogate credential before it is used, and it is distinct from the cryptographic mechanisms that bind a token to a specific device, merchant, or channel.

Payment Processors and Token Service Providers

Token service providers generate the payment token and incorporate it into the target domain, coordinating with the requesting party and the issuer. Processors integrating network tokenization should understand that provisioning is triggered at enrollment or checkout and is separate from the token's later transactional use.

Compliance and Security Teams

Teams assessing PCI DSS scope need to distinguish tokenization from encryption, truncation, masking, and hashing, and to evaluate each provisioning implementation on its architecture and validation rather than its label. Applicable requirements should be confirmed against the current published PCI DSS standard.

Inside Token Provisioning

Token Requestor

The entity that initiates a request for a payment token, such as a wallet provider, merchant, or acquirer. Token requestors are typically identified and registered with the token service provider before provisioning can occur.

Token Service Provider (TSP)

The party that generates, issues, and maintains payment tokens and the mapping between a token and the underlying PAN. TSP roles are often performed by card networks or their designated providers under network token programs, which are governed by card brand rules rather than by PCI DSS itself.

Identification and Verification (ID&V)

The process performed during provisioning to establish that the party requesting a token is authorized to use the underlying account. ID&V is intended to reduce the risk of provisioning a token to a fraudulent actor; its rigor and methods depend on the issuer and network implementation.

Token-to-PAN Mapping (Token Vault)

The secure repository maintained by the TSP that links an issued token to its corresponding PAN. Because the PAN is cardholder data, the vault and its access controls fall within the scope of controls that must be assessed against the current published PCI DSS.

Token Domain Restriction Controls

Attributes that constrain where and how a token may be used, such as limiting it to a specific merchant, channel, or device. These controls are intended to limit the usefulness of a token if it is exposed, but their effectiveness depends on correct implementation and enforcement.

Token Cryptogram / Dynamic Data

Transaction-specific data that may accompany a provisioned token to help validate that the token is being used legitimately. This differs from static cardholder data and is distinct from sensitive authentication data such as full track data, CVV2/CVC2/CAV2, or PIN blocks.

Common questions

Answers to the questions practitioners most commonly ask about Token Provisioning.

Is token provisioning the same as encrypting the PAN?

No. Token provisioning is not encryption. Encryption transforms a PAN into ciphertext that can be reversed with the appropriate key, so the original value remains mathematically recoverable and the ciphertext generally stays in scope where keys are present. Token provisioning generates or issues a surrogate value (token) that stands in for the PAN, typically without a mathematical relationship that can be reversed outside the controlled token vault or service. The two techniques transform data differently, and their effect on PCI DSS scope depends on implementation and validation rather than on the label alone.

Does provisioning a token automatically take a system out of PCI DSS scope?

Not automatically. Whether tokenization reduces scope depends on how the token is generated, how the mapping between token and PAN is stored and controlled, whether the original PAN is ever present in a given environment, and how the deployment is validated. A system that provisions or handles tokens may still be in scope if it can retrieve or de-tokenize the PAN, or if cardholder data is present at any point. Scope reduction is a validation outcome, not a property of using the word token. Confirm the specific controls against the current published PCI DSS.

Where should the token vault or token-to-PAN mapping be stored during provisioning?

The mapping between a token and its underlying PAN is typically held in a controlled token vault or equivalent service that remains in PCI DSS scope, since it can associate a surrogate value back to cardholder data. Access to this mapping should be restricted, monitored, and protected under the relevant PCI DSS requirements for the version in use. Environments that consume tokens but cannot reach the vault or de-tokenize may have reduced scope, but this depends on the specific architecture and how it is validated.

Can sensitive authentication data be retained to support token provisioning?

No. Sensitive authentication data — including full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks — must not be stored after authorization, even when encrypted, regardless of any tokenization process. Token provisioning may substitute for the PAN, which is cardholder data that can be stored under defined controls, but it does not create an allowance to retain sensitive authentication data. Provisioning workflows should be designed so that these elements are not persisted post-authorization.

How should systems handle de-tokenization requests after a token is provisioned?

De-tokenization — retrieving the original PAN from a token — should be limited to the smallest possible set of systems and roles that have a defined business need, since any component able to de-tokenize is generally in PCI DSS scope. Access should be authenticated, authorized, and logged, and the retrieval path should be protected consistent with the applicable PCI DSS requirements for the version in use. Minimizing where de-tokenization is possible helps reduce the environment that must be validated.

What distinguishes token provisioning from masking or truncation of a PAN?

Token provisioning issues a surrogate value that can, within controlled systems, be associated back to the full PAN through a vault or service. Masking hides portions of the PAN for display without necessarily removing the full value from storage, and truncation permanently removes a portion of the PAN so the full value cannot be reconstructed from the truncated data alone. These techniques transform data differently and are not interchangeable; their impact on PCI DSS scope depends on implementation and validation rather than on the terminology used.

Common misconceptions

Token provisioning is the same as encrypting the PAN.

Tokenization and encryption are different techniques. Encryption transforms data using a reversible cryptographic process, while tokenization substitutes a surrogate value that maps back to the PAN through a separate lookup, typically held by a token service provider. Whether either approach reduces PCI DSS scope depends on implementation and validation, not on the label alone.

Provisioning a token removes all systems from PCI DSS scope.

Provisioning can reduce the exposure of PAN in some environments, but the token vault, the token-to-PAN mapping, and systems that can request de-tokenization or that handle cardholder data remain subject to applicable controls. Scope reduction must be assessed against the current published PCI DSS rather than assumed.

Once a token is provisioned, fraud is prevented.

Token provisioning with ID&V and domain restriction controls is intended to help reduce certain fraud risks, such as reuse of an exposed token. It does not eliminate fraud; risks such as account takeover during provisioning, first-party fraud, or fraud through other channels may remain, and detection controls carry false-positive and false-negative trade-offs.

Best practices

Apply risk-based identification and verification (ID&V) during provisioning to help confirm the requestor is authorized for the underlying account, and calibrate its rigor to the associated fraud risk rather than treating it as a one-time formality.

Protect the token vault and token-to-PAN mapping as cardholder data assets, applying access controls, logging, and assessment consistent with the current published PCI DSS, and do not assume tokenization alone removes them from scope.

Configure token domain restriction controls, such as merchant, channel, or device limitations, so that an exposed token has limited usefulness, and verify these restrictions are enforced in practice.

Ensure sensitive authentication data, including full track data, CVV2/CVC2/CAV2, and PIN blocks, is not retained after authorization as part of any provisioning workflow, even when encrypted.

Confirm the roles and responsibilities of token requestors and the token service provider against the applicable card network token program rules, recognizing these rules vary by region and change over time.

Validate scope-reduction claims for tokenization through assessment and evidence rather than relying on the label, and document how de-tokenization access is restricted and monitored.