Skip to main content
Commerce Security Authority
Category: Tokenization

Token Requestor

Also known as: Token Requester
Simply put

A Token Requestor is an entity, such as a merchant or digital wallet, that is authorized to ask a token service provider to issue payment tokens in place of an actual card number. Each Token Requestor is identified by a unique Token Requestor ID (TRID), which must be established before it can request tokens. This arrangement is intended to help keep the underlying card details out of the requesting entity's systems.

Formal definition

A Token Requestor is a registered entity (for example, a merchant, payment processor, or wallet provider) authorized to submit tokenization requests to a Token Service Provider (TSP) and receive network tokens in return. It is identified by a Token Requestor ID (TRID), a unique code assigned to entities permitted to request payment tokens; in EMVCo-aligned schemes the TSP Code is embedded within the Token Requestor ID so that the identifier uniquely represents the pairing of a specific Token Requestor with a specific TSP. Obtaining a TRID is typically a prerequisite for requesting network tokens, and each tokenization request is authorized according to the relevant token program's implementation rules (for example, MDES) before a card is approved for tokenization. Note that network 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 a token alone.

Why it matters

The Token Requestor concept is central to how network tokenization is governed and controlled. Because a Token Requestor must be registered and assigned a unique Token Requestor ID (TRID) before it can request tokens, the model establishes a clear chain of accountability: the Token Service Provider knows which entity is requesting tokens and can authorize each request according to the relevant token program's implementation rules, such as MDES. This structure is intended to help keep the underlying card number out of the requesting entity's systems, since the entity works with network tokens rather than the actual Primary Account Number.

For merchants, processors, and wallet providers, understanding the Token Requestor role matters because obtaining a TRID is typically a prerequisite for enabling network tokenization at all. Without a registered Token Requestor identity paired with a specific TSP, an entity cannot request or receive network tokens. The TRID also creates a traceable pairing between a specific Token Requestor and a specific Token Service Provider, which supports controlled issuance and management of tokens across programs.

It is important not to overstate what tokenization achieves. Network tokenization performed 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 rather than on the use of a token alone. Being a Token Requestor and holding a TRID does not by itself reduce compliance obligations; scope outcomes must be assessed against the current published standard and the actual data flows in place.

Who it's relevant to

Merchants and digital wallet providers
Merchants and wallet providers commonly act as Token Requestors, using a TRID to request network tokens from token providers in place of storing actual card numbers. Because holding a TRID is typically a prerequisite for enabling network tokenization, these entities need to complete registration before they can operate. They should also confirm how their specific implementation affects PCI DSS scope rather than assuming a token alone changes their obligations.
Payment processors and acquirers
Processors and acquirers may serve as Token Requestors on behalf of merchants or facilitate the registration and use of TRIDs. Understanding the pairing between a Token Requestor and a specific Token Service Provider helps them manage token issuance across programs and route tokenization requests to be authorized under the applicable program implementation rules.
Token Service Providers
TSPs assign and manage Token Requestor IDs and authorize each tokenization request according to the relevant token program's implementation rules before a card is approved for tokenization. In EMVCo-aligned schemes, the embedding of the TSP Code within the TRID lets the TSP uniquely identify the requesting entity paired with itself, supporting controlled issuance.
Compliance officers and PCI DSS assessors
Compliance and assessment teams need to distinguish network tokenization from encryption, truncation, masking, and hashing, and to evaluate its effect on PCI DSS scope based on the actual implementation and validation rather than the presence of a token. They should confirm requirements against the current published standard when assessing environments that rely on Token Requestor arrangements.

Inside Token Requestor

Token Requestor
An entity that requests the provisioning of payment tokens from a token service provider (TSP) on behalf of a use case, such as a mobile wallet, e-commerce merchant, card-on-file service, or device manufacturer. The token requestor initiates the request but is distinct from the entity that generates and manages the tokens.
Token Requestor ID (TRID)
A unique identifier assigned to a token requestor by the token service provider or governing token program. It allows tokens and token-related transactions to be associated with the specific requestor and its registered use case and domain controls.
Token Service Provider (TSP)
The distinct entity that generates, provisions, and manages tokens and maintains the mapping between a token and the underlying PAN. The token requestor requests tokens from the TSP; the two roles should not be conflated, as the TSP holds the token vault while the requestor consumes the resulting tokens.
Registration and onboarding
The process by which a prospective token requestor is vetted and approved to participate in a tokenization program, including agreement to program rules, identification and verification (ID&V) expectations, and assignment of a Token Requestor ID before tokens can be requested.
Domain restriction controls
Attributes that constrain how a provisioned token may be used, such as channel, merchant, or device. These controls are configured in connection with the requestor's registered use case and are intended to limit the utility of a token if it is compromised.
Relationship to underlying PAN
The token requestor typically handles tokens rather than the underlying primary account number. Whether and how this affects PCI DSS scope depends on the specific implementation, the data actually handled, and validation, not on the token requestor label alone.

Common questions

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

Is a token requestor the same thing as a payment tokenization service or token service provider?
No. These are distinct roles within an EMV payment tokenization ecosystem. The token service provider (TSP) is the entity that operates the tokenization system, generates and issues payment tokens, and typically maintains the mapping between tokens and the underlying PAN. The token requestor is the entity that asks the TSP to issue a token for a specific use case, such as a digital wallet, a card-on-file merchant, or an in-app payment provider. A single organization could in theory perform more than one role, but the terms describe different functions and should not be used interchangeably. Readers should confirm role definitions against the applicable EMVCo tokenization framework and card brand program rules, which vary by network and region.
Does obtaining a payment token from a token requestor mean cardholder data is no longer in scope for PCI DSS?
Not automatically. The effect of tokenization on PCI DSS scope depends on the specific implementation, how tokens are generated and mapped, where and how any underlying PAN is stored or accessible, and how the deployment is validated, not on the presence of a token requestor role by itself. Tokenization can reduce scope when properly designed and validated, but scope reduction must be assessed against your actual data flows and controls. It is also important to distinguish payment tokens in the EMV sense from tokens produced by other tokenization approaches, and to remember that tokenization is different from encryption, truncation, masking, and hashing. Confirm scope conclusions with a qualified assessor and against the current published PCI DSS.
How does an entity become an approved token requestor?
Becoming a token requestor generally involves registering with the relevant token service provider or card brand tokenization program and being assigned a token requestor identifier used to associate token requests with that entity. Onboarding requirements, identifiers, and approval processes are defined by the applicable EMVCo framework and by individual card brand and network program rules, which change over time and vary by region. Confirm current requirements, documentation, and any associated obligations directly with the token service provider and card brands you intend to work with rather than assuming a uniform process across networks.
What security responsibilities does a token requestor typically retain?
A token requestor typically remains responsible for protecting the data and credentials involved in requesting and using tokens, for authenticating and verifying the cardholder or account within its defined use case, and for handling any cardholder data it processes before or during a token request in accordance with applicable requirements. The presence of a token generally does not remove all obligations, and any sensitive authentication data must not be stored after authorization even when encrypted. Specific responsibilities depend on the token program agreements and on your role in the transaction flow; confirm them against program rules and the current PCI DSS.
Does using a token requestor and payment tokens eliminate card-not-present fraud?
No. Payment tokenization is intended to reduce the value of stored or transmitted account data if it is compromised, but it does not by itself authenticate the cardholder or eliminate fraud. Tokenization addresses a different concern than cardholder authentication controls such as 3-D Secure, strong customer authentication, or multi-factor authentication, and none of these individually eliminates card-not-present fraud. A layered approach may help reduce fraud, and each control carries trade-offs, including potential false positives and false negatives in any associated detection. Evaluate tokenization as one element of a broader fraud and data-protection strategy.
How should a token requestor coordinate token lifecycle events such as suspension or deletion?
Token lifecycle management, including provisioning, suspension, resumption, and deletion, is typically coordinated between the token requestor and the token service provider according to the interfaces and rules defined by the applicable tokenization framework and card brand programs. A token requestor should understand which lifecycle actions it can initiate, how those actions are communicated, and how they relate to the underlying account status. Because these processes and available operations vary by network and change over time, confirm the supported lifecycle events and their handling directly with your token service provider and against current program documentation.

Common misconceptions

A token requestor and a token service provider are the same role.
They are distinct. The token service provider generates and manages tokens and maintains the token-to-PAN mapping, while the token requestor requests tokens for a defined use case. A single organization may perform both functions in some architectures, but the roles and responsibilities remain separate.
Becoming a token requestor and using tokens automatically removes an entity from PCI DSS scope.
Tokenization can reduce scope, but the effect depends on the implementation, what data the entity actually stores, processes, or transmits, and on validation. Handling tokens does not by itself eliminate scope; any residual access to cardholder data or to systems that can retrieve it must be assessed against the current PCI DSS.
Tokens obtained by a token requestor are protected the same way regardless of use because they are not the PAN.
A token's protective value comes largely from domain restriction controls tied to the registered use case, not from the substitution alone. Tokenization also differs from encryption, truncation, masking, and hashing, which transform or reduce data differently and have different effects on scope and reversibility.

Best practices

Maintain clear documentation of the boundary between your role as token requestor and any token service provider you rely on, including what data each party stores, processes, and transmits.
Safeguard your Token Requestor ID and associated credentials, and treat provisioning requests as sensitive operations subject to access control and monitoring.
Configure and verify domain restriction controls to match the registered use case, so provisioned tokens are limited to their intended channel, merchant, or device.
Do not assume tokenization removes PCI DSS scope; assess and validate your actual data flows against the current published standard and confirm requirement wording for the applicable version.
Ensure sensitive authentication data such as full track data, card verification values, and PINs is not stored after authorization, even where tokenization is in use.
Review token program rules, onboarding obligations, and identification and verification expectations periodically, and confirm details against current program documentation rather than assumptions.