Exchanging money for goods and services has always come with the need for protection. Whether we are looking at cash, checks, payment cards or even crypto coins, fraud prevention is key. It ensures the legitimacy and trust necessary for these payment mechanisms to be socially acceptable.

When we focus on payment cards, a number of protection methods have been introduced over time. These include cardholder authentication mechanisms like the use of PIN or CVV2, the use of magnetic stripe data using the EMV chip, card data encryption during transmission and the use of tokenization.

In this article, we will focus on tokenization. We will analyze its applications and its use in mobile payments with digital wallets (Mobile Wallets). And, how fraud can be prevented.

How is payment card data captured and stored in mobile wallets?

A digital wallet is an application that allows you to store and organize loyalty cards, identification documents, bank details, concert tickets, airline tickets, crypto coins and payment cards on a mobile phone, a computer, a smart watch or on a tablet. This data can then be transmitted to other devices using wireless technologies (NFC or Bluetooth) to make payments or perform specific validations. This frees the user from the use of physical cards. Mobile wallet providers include Apple Pay, Google Pay and Samsung Pay.

Linking or registering a payment card (credit or debit) with one of these mobile wallets is usually a fairly straightforward process. Only a device that meets the installation prerequisites is required. The payment card data is scanned or manually entered into the application and sent for validation to the payment network. At the end of this process, the user can make payments on the accepted terminals using their mobile device instead of using the physical card.

The interesting thing about this technology is that the actual data of the linked payment card is never shared with the merchant when making payments. Nor is it stored in the user's device. This radically minimizes the risk of fraud and exposure of this information. This security feature is based on a functionality called "tokenization".

What is tokenization and what types of tokens are there?

The tokenization is the process of replacing confidential data with non-confidential data (called "token"). This token data guarantees the same functionality, with the additional characteristic that from the token data itself it is not possible to obtain or infer the confidential data with which it is related. 

Think of gambling chips in a casino. These chips are exchanged for real money. They allow the user to gamble within the casino without needing actual cash. If the chips are stolen, they cannot be used in other casinos. This limits the thief’s field of action and acts foremost as a crime deterrent. This is called ‘devaluation’.

In the card payments industry, a token is a non-confidential value used to replace the Primary Account Number (PAN) data. However, in this area, not all tokens are the same. They vary depending on numerous variables under three main categories: Acquiring Tokens, Issuer Tokens and Payment Tokens.

Table-1-ENG

In the case of mobile payment applications (Apple Pay, Google Pay, Samsung Pay, Microsoft Wallet, Fitbit Pay and Garmin Pay, among others), payment tokens (EMV tokens) are used.

What is a payment token and how is it used in mobile wallets?

A payment token differs from the acquisition and issuer tokens in that its format follows the parameters described in the EMVco technical specification. Their routing and processing in payment networks follow the same steps as a normal transaction without the need to expose the original PAN, minimizing the risk and need for regulatory compliance in those merchants that make use of this method.

The management of these type of tokens is under the responsibility of entities registered with EMVco as Token Service Provider (TSP). The TSPs handle:

  • Generation and issuance of payment tokens.
  • Operation and administration of the Token Vault (database in which the original PAN and its corresponding token are stored, together with other transactional data).
  • Assignment of tokens.
  • Token life cycle management.
  • Management of the token-PAN relationship and de-tokenization processes.
  • Operation and administration of the underlying cryptographic platform for the execution of tokenization functions.
  • Maintenance of the security of the token management environment. The security controls to be implemented are described in the PCI TSP Security Requirements standard.

These TSPs, in turn, offer their tokenization services to entities called Token Requestors (TR), who must be registered with the TSP to initiate token requests. In the case of Apple Pay, Google Pay and Samsung Pay, the companies behind these applications act as Token Requestors.

In general terms, the process for registering a card in a mobile wallet is as follows:

  1. The cardholder uses a device that supports the digital wallet application and registers a card, entering the data into the application.
  2. The application sends the data to a Token Requestor (TR).
  3. The TR sends the data to the Token Service Provider (TSP) with which it is registered and makes a registration request for a new token.
  4. The TSP verifies the data with the card issuer.
  5. If everything is correct, the TSP registers the PAN and links it to a new token in a secure database (Token Vault). Along with the TR identifier, the token expiration date, and a number of additional security features called Token Domain, including restrictions on the use of the new token on certain channels, use by a particular merchant, limitation on the number of permitted uses, and verification of the cryptogram.
  6. The TSP notifies the application of the newly generated token.
  7. The application stores the generated token (Device Account Number (DAN) for Apple Pay or Digitized PAN (DPAN) for Samsung Pay) in a secure location (Secure Element (SE) or Host Card Emulation (HCE)).

Advantio_Payment token creation request diagramFigure 1. Payment token creation request diagram

The original PAN of the card is never stored on the end user's device. Instead, the payment token with which subsequent transactions are made is securely stored. Let’s walk through this:

  1. The cardholder (in this case, the same user of the digital wallet application) makes use of the payment application, presenting the payment token to the merchant from his/her device using any of the following channels:
    • EMV Contactless: If the Point of Sale (POS) terminal supports contactless payments via NFC (Near Field Communication), the EMV contactless specification is used to perform the data transfer.
    • Contactless MSD: If the payment terminal does not support contactless payments under the EMV specification, then the device can employ the contactless MSD (magnetic stripe data) mode that emulates a magnetic stripe transaction.
  2. The merchant sends the token and dynamic cryptogram data to the acquirer.
  3. The acquirer routes the transaction to the payment network in the same way as a normal transaction would proceed.
  4. The payment network determines that it is a token and not a PAN, as the token has a specific BIN. It thereby routes the transaction to the related Token Service Provider (TSP).
  5. The TSP validates the token, the related cryptogram, the Token Requestor (TR) identifier and the Token Domain usage restrictions. If everything is correct, proceed with de-tokenization and sends the original PAN data to the payment network.
  6. The payment network sends the original PAN data to the sender.
  7. The issuer validates the transaction with the original PAN data and sends the response to the payment network.
  8. The payment network replaces the original PAN with the payment token initially received and sends it to the acquirer.
  9. The acquirer notifies the merchant of the result of the transaction.

Advantio_Diagram of the transactional process for payments with EMV tokensFigure 2. Diagram of the transactional process for payments with EMV tokens

Under this flow, both the merchant and the acquiring entity do not have access to the original PAN. This is why the risk of fraud is minimal.

How do payment tokens relate to PCI SSC standards?   

PCI SSC standards are applied to each element of the process. This ensures the transactional ecosystem with payment tokens (or EMV tokens) is sufficiently secure.

Table-2-ENG

Ensuring comprehensive security

Contactless mobile transactions are an integral part of new technologies linked to digital payments. Mobile phones, smart watches, laptops, tablets and wearable devices have changed the traditional way of making payments. It is no longer necessary to carry the plastics of payment cards, whose functionality has been replaced by mobile wallet applications.

In terms of risk, the use of these devices opens up a new attack vector for confidential payment data. At this point, tokenization functionalities become part of the arsenal of fraud protection: by replacing sensitive data with non-confidential data the impact of a potential attack is minimized, as the target (card data) is devalued.

The widespread use of this new tokenization strategy is already part of the priorities of the different payment brands to support the growing use of digital payments. The integration of security standards such as PCI DSS with the new standards applicable to tokenization service providers (PCI TSP) ensures comprehensive security within the digital payment ecosystem.

Advantio_MobileWallets_CTAbanner_V1.0

Resources:

1. Increasing Security and Reducing Fraud with EMV Chip and PCI Standard https://www.pcisecuritystandards.org/documents/EMV-Letter.pdf 
2. Securing Account Data with the PCI Point-to-Point Encryption Standard  https://www.pcisecuritystandards.org/documents/P2PE_At_a_Glance_v2.pdf
3. Fight Cybercrime by Making Stolen Data Worthless to Thieves https://www.pcisecuritystandards.org/documents/PCI-CyberCrime-FinalR.pdf
4. Information Supplement: Tokenization Product Security Guideline https://www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf
5.  EMV® Payment Tokenisation Specification – Technical Framework https://www.emvco.com/emv-technologies/payment-tokenisation/
6. Deciphering Virtual Card Numbers and PCI DSS Compliance https://event.webcasts.com/viewer/event.jsp?ei=1116927
7.  All you need to know about Tokenization https://usa.visa.com/dam/VCOM/Media%20Kits/PDF/visa-security-tokenization-infographic.pdf
8. Token Service Provider Registration Programme https://www.emvco.com/processes-forms/registration-services/tsp-code/
9. PCI TSP Security Requirements https://www.pcisecuritystandards.org/documents/PCI_TSP_Requirements_v1.pdf
10. Visa Token Service and Apple Pay https://usa.visa.com/partner-with-us/payment-technology/apple-pay.html.html
11.  Google Pay: How payments work https://support.google.com/pay/merchants/answer/6345242?hl=en y https://usa.visa.com/partner-with-us/payment-technology/google-pay-issuers.html
12. Samsung Pay: Tokenization https://developer.samsung.com/tech-insights/pay/tokenization y https://usa.visa.com/partner-with-us/payment-technology/samsung-pay-issuers.html
13. The EMV® Contactless Specification https://www.emvco.com/emv-technologies/contactless/

Column Header Text Column Header Text Column Header Text

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving
  • Their work should have not stopped there because achieving

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Their work should have not stopped there because achieving compliance is an occasional result that doesn't ensure a continual protection.

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Performing a review of the media inventories at least annually

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Row Header Text

Lorem ipsum dolor sit

Lorem ipsum dolor sit

23

Discover More

Advantio_Blog_DNS_Diagram_V1 Image caption goes here. This is HTML text.

I am the Senior Security Consultant in Advantio. I have more than 15 years of experience, working both in South America and Europe. My information security background includes consultancy and audit, training, implementation of security technologies and design and policy development among others.

Certifications: CISSP, CISM, CISA, CRISC, CEH, CHFI, PCI QSA, QSA (P2PE), 3DS Assessor

Schedule a call with an expert