EMV Payment Tokenisation – Technical Questions

General Payment Tokenisation Questions

  1. How does Payment Tokenisation compare with strong encryption as another way of securing cardholder data?
  2. Are Payment Tokens the same length as its associated PAN?
  3. Can a single PAN be bound to multiple Payment Tokens?
  4. Could the Payment Token linked to a PAN be updated, if necessary?

Use Case Implementation Related Payment Tokenisation Questions

  1. In the Mobile QR code (QRC) use case, QRC may be easily copied and stored. Are there plans to create one-time use QRC Payment Tokens or have a short validity period to enhance its security? Will the QRC contain only the Payment Token or will it include other dynamic components issued by the QRC service provider?
  2. In the specification, a payment enabler such as Original Equipment Manufacturer (OEM) device manufacturers could act as a Token Requestor. Does this mean that a handset provider's OEM could also request Payment Tokens? Can a telecommunications service provider also be the Token Requestor?

Merchant Related Payment Tokenisation Questions

  1. Can the Merchant/Acquirer match a Payment Token to the partial PAN (last 4 digits), in order to handle exception cases and chargeback flows?
  2. In the card-on-file merchant use case, if Merchant X is approved by a Token Service Provider to be a Token Requestor, could it then provide Token Request services for Merchant Y as well?
  3. The Assigned Token Assurance Level is one of the key outputs of a Token Request. How would this be used in a Payment Token-based transaction?

Token Service Provider/Card Issuer Related Payment Tokenisation Questions

  1. In the specification, the Token Service Provider already plays a role as an authorised party, managing issuance, security control and other functions related to the Payment Token. Could the Token Service Provider play other roles, such as a Payment Processor?
  2. In the specification Figure 2, the Payment Network initiates the de-tokenisation function. Does this mean that only the Payment Network could be a Token Service Provider?
  3. Who can perform TSP services for a given BIN Range that allows token issuance?
  4. Should Token Service Providers apply to ISO/IEC JTC1 SC17/WG5 for new IINs (BINs) since the Token Service Provider will manage the Token BIN and Token BIN Range?
  5. Why is Identification and Verification performed by the Card Issuer or Token Service Provider?
  6. In the specification Figure 1, the Token Service Provider connects to the Card Issuer for Token Assurance Identification and Verification. Does this mean that the connection is physical (i.e. directly to the Card Issuer) or logical (i.e. the Token Service Provider connects to the Payment Network first and then transfers the data through the Payment Network to the Card Issuer)?
  7. In the specification, section 6 provides several examples of different Identification and Verification methods. This is a process within each use case combining risk mechanisms, account verification and Cardholder authentication together and may require cooperation by Card Issuers and Token Requestors. Does EMVCo have plans to further define Identification and Verification methods in more detail within the Payment Token Specification?
  8. Is there any plan for EMVCo to validate implementations according to the Payment Token Specification?
  9. I have ideas, concerns and questions to make sure this specification is implementable in my specific market, where can I download the specification and participate further?

General Payment Tokenisation Questions

  1. How does Payment Tokenisation compare with strong encryption as another way of securing cardholder data?

    Payment Tokens can help card-on-file merchants and digital wallet providers to greatly reduce the threat and consequences of a potential data breach. While encryption provides this as well, encrypted data cannot be processed without being first decrypted, thereby not fully alleviating the risks of a potential security breach. Brick and mortar merchants, however, may wish to use encryption to protect their transaction data since they cannot ensure that they will only process tokenised card/mobile transactions.

  2. Are Payment Tokens the same length as its associated PAN?

    The Payment Token is a 13 to 19 digit numeric value that passes basic validation rules of an account number, including the Luhn check digit. Generally Payment Tokens are the same length as the PAN they replace, though this is not a requirement. Payment Tokens are generated within a BIN range that has been designated as a Token BIN Range and flagged accordingly in all appropriate BIN tables. Payment Tokens must not have the same value as or conflict with a real PAN.

  3. Can a single PAN be bound to multiple Payment Tokens?

    Yes, one PAN may have multiple Payment Tokens associated with it depending on the use case and the payment domain assigned to the Token Requestor.

  4. Could the Payment Token linked to a PAN be updated, if necessary?

    Payment Tokens may be updated for a variety of reasons, such as in the event of a lost or stolen device.

Use Case Implementation Related Payment Tokenisation Questions

  1. In the Mobile QR code (QRC) use case, QRC may be easily copied and stored. Are there plans to create one-time use QRC Payment Tokens or have a short validity period to enhance its security? Will the QRC contain only the Payment Token or will it include other dynamic components issued by the QRC service provider?

    The Mobile QR code use case is an example of how tokenisation could be used in an emerging acceptance environment. Currently EMVCo does not specify QR code solutions. However, the example use case illustrates how a QR code could include a token cryptogram to protect against reuse.

  2. In the specification, a payment enabler such as Original Equipment Manufacturer (OEM) device manufacturers could act as a Token Requestor. Does this mean that a handset provider's OEM could also request Payment Tokens? Can a telecommunications service provider also be the Token Requestor?

    Yes, a handset provider's OEM or a telecommunications service provider could be a Token Requestor if approved by the Token Service Provider.

Merchant Related Payment Tokenisation Questions

  1. Can the Merchant/Acquirer match a Payment Token to the partial PAN (last 4 digits), in order to handle exception cases and chargeback flows?

    Yes, where a Token Service Provider has enabled this capability, the last 4 digits of the PAN would be transferred back to the Merchant/Acquirer for business use.

  2. In the card-on-file merchant use case, if Merchant X is approved by a Token Service Provider to be a Token Requestor, could it then provide Token Request services for Merchant Y as well?

    Yes, if Merchant X has contractual agreements to provide payment acceptance services to Merchant Y, then Merchant X's Payment Tokens could be used at Merchant Y, so long as the Token Service Provider can perform all necessary Token Domain Restriction Controls needed to ensure that the Payment Tokens cannot be used at non-participating merchants.

  3. The Assigned Token Assurance Level is one of the key outputs of a Token Request. How would this be used in a Payment Token-based transaction?

    The Assigned Token Assurance Level indicates the level of Identification and Verification performed at the time the Payment Token was issued (or at subsequent times post-issuance). It may be used to drive proprietary business rules as defined by each Payment Network that could make specific rules pertaining to Token Assurance levels depending on supported use cases.

Token Service Provider/Card Issuer Related Payment Tokenisation Questions

  1. In the specification, the Token Service Provider already plays a role as an authorised party, managing issuance, security control and other functions related to the Payment Token. Could the Token Service Provider play other roles, such as a Payment Processor?

    The Token Service Provider may be a wholly independent party from the Payment Network or Payment Processor or alternatively a Token Service Provider could be integrated with a Payment Network or Payment Processor.

  2. In the specification Figure 2, the Payment Network initiates the de-tokenisation function. Does this mean that only the Payment Network could be a Token Service Provider?

    No, Figure 2 is an example implementation where the Payment Network is the Token Service Provider. Other organisations, such as Card Issuers or third party service providers could act as a Token Service Provider.

  3. Who can perform TSP services for a given BIN Range that allows token issuance?

    The authorised user of the BIN.

  4. Should Token Service Providers apply to ISO/IEC JTC1 SC17/WG5 for new IINs (BINs) since the Token Service Provider will manage the Token BIN and Token BIN Range?

    The specification does not necessarily require new IINs beyond those already licensed from ISO. In general Token Service Providers will need to use existing IINs for Token Issuance so that the Payment Tokens can pass through the payment network without coding changes being required by each entity in the processing chain.

  5. Why is Identification and Verification performed by the Card Issuer or Token Service Provider?

    Identification and Verification is a method through which either the Token Service Provider or Card Issuer may validate the Cardholder and the Cardholder's account to establish the Token Assurance Level for the Payment Token. Since the Card Issuer is responsible for managing the Cardholder's account information, the Card Issuer will be able to evaluate this Token Assurance Level when a transaction occurs. The Token Service Provider can alternatively, or in conjunction with the Card Issuer, perform risk analysis with the information collected to help establish the Token Assurance Level.

  6. In the specification Figure 1, the Token Service Provider connects to the Card Issuer for Token Assurance Identification and Verification. Does this mean that the connection is physical (i.e. directly to the Card Issuer) or logical (i.e. the Token Service Provider connects to the Payment Network first and then transfers the data through the Payment Network to the Card Issuer)?

    In the specification Figure 1, the data flow connection between the Token Service Provider and Card Issuer could be physical or logical. There is no requirement or restriction and entities may determine what business and technical objectives work best for them, respectively.

  7. In the specification, section 6 provides several examples of different Identification and Verification methods. This is a process within each use case combining risk mechanisms, account verification and Cardholder authentication together and may require cooperation by Card Issuers and Token Requestors. Does EMVCo have plans to further define Identification and Verification methods in more detail within the Payment Token Specification?

    EMVCo will continue to assess industry need and where appropriate further define aspects of the EMV Payment Token Specification – Technical Framework v1.0.

  8. Is there any plan for EMVCo to validate implementations according to the Payment Token Specification?

    EMVCo will continue to assess industry need as regarding potential testing and evaluation programmes it might put in place for the EMV Payment Tokenisation Specification – Technical Framework v1.0.

  9. I have ideas, concerns and questions to make sure this specification is implementable in my specific market, where can I download the specification and participate further?

    As a global technical body, EMVCo ensures that its ISO-based specifications are open for use across different markets and in different environments, and can support a truly interoperable global payments framework. We encourage all industry stakeholders to engage in our work and contribute to the development of the EMV Specifications to enable smarter and more secure payments. The EMV® Payment Tokenisation Specification - Technical Framework v1.0 was published in March 2014 on our website www.emvco.com and can be downloaded by anyone without charge and implemented royalty-free. Our aim in publically sharing this specification framework is to promote transparency, maximise industry engagement and encourage market comments so that the document can evolve in line with commercial and technical market requirements. We have already witnessed significant interest and call on other parties to get involved through the EMVCo Associates Programme, a framework that allows stakeholders to play an active role in providing input to the technical and operational issues connected to the EMV Specifications and related processes. In addition to this, EMVCo also engages with other industry bodies, including many merchant groups globally, to understand and support individual sector requirements.