Tokenization and Securing Mobile Payments Apps

The use of mobile payments is expected to continue to rise and become the second most popular payment method after debit cards by 2022. In 2017, China’s mobile payments market was estimated at $17 trillion. The growth of mobile payments depends totally on the prevention of data breaches, and for this, there is an important technology that should be designed into the mix of security mechanisms: Tokenization.

Tokenization is the act of replacing sensitive data like the PAN (Primary account number) with tokens, which is useless data that can be mapped to the original data that is kept in secure vaults.

Linking or registering a payment card (credit or debit) with most mobile wallets is usually a straightforward process. The payment card data are manually entered or scanned into the application and sent for validation to the payment network. Once validated, users can make payments at terminals using their smartphones, tablets or wearable devices instead of using the physical card.

Even if the card’s PAN is stored within a secure location in the device (secure element), this doesn’t totally prevent data breaches. For instance, the PAN could be intercepted during the transaction workflow. 

Hence it is “general” practice in M-Payments to replace the PAN with a token using the like-for-like format rule. Simply put, 16-digit PAN is replaced by a 16-digit token that is usually randomly generated.

For example instead of using the PAN:

4085-8800-8378-3527 

the mobile payment operator will use the token:

1454-0989-2121-8954

The token is completely useless unless it can be de-tokenized to the original PAN.

Here we present some of the most popular mobile wallets and how they use tokenization technology.

In fact, most if not all mobile payments are using some form of tokenization with access tokens, even if they do not explicitly use credit card tokenization, where the user:

• Authenticates itself using passcode, biometrics, etc;
• Gets identified on the payment servers;
• Gets the credit card details used to charge the bank account.

For example, Square Wallet uses the picture of the user’s face as a “token” to mask the payment card data. Braintree (Venmo) uses the fingerprint of the device, the user’s location, and a password to generate the access “self-authenticating” token. It is not exactly the philosophy of credit card tokenization because sensitive data is masked by other sensitive data.

Nevertheless, all mobile payments are capitalizing on several tokenization systems. Credit card data are stored in the cloud, and even if it is not explicitly tokenized, it certainly does not reside on the mobile device. This is a big difference with EMV payments, where credit card data is stored on the card itself.

Some mobile payments are using “high-value” tokens that can be used in lieu of credit card data to place transactions, while others do not. M-Payments that seem to implement a “true” credit card tokenization are Apple Pay, Google Pay, and Samsung Pay. Let’s see how the latter works under the hood.

Mobile Payments Tokenization: The Samsung Pay Example

Samsung Pay is an interesting example of tokenization that combines HCE (Host Card Emulation) and tokenization. This application is only available for compatible Samsung phones or watches.

Samsung Pay works through NFC, but is also able to simulate a bank card magnetic stripe (Samsung’s MST technology). Therefore, it can be accepted in any shop where “traditional” credit cards are accepted.  

The tokenized PAN is called a “token PAN” or digitized PAN (DPAN). The token protects the real credit card number from being intercepted and fraudulently used. 

The Samsung Payment tokenization then adds a cryptogram to the payment information + DPAN. The cryptogram is unique and generated by the device. It shows the card network that the card has been legitimately used.

Samsung Pay primarily utilizes the tokenization services offered by global payment networks, depending on the card issuer. However, third parties are also supported. The card issuer decides the rules and parameters of the token service, performs account verification during the token request, and then authorizes transactions.