4 min read

How to Secure Mobile Payment Apps with Tokenization

How to Secure Mobile Payment Apps with Tokenization

The use of mobile payments is expected to continue to rise and become the second most popular payment method after debit cards by 2022. Analysts predict that China's mobile payments market will attain a value of ¥1,800 trillion by 2025.

However, the continued growth of the mobile payments market depends, to a large extent, on the prevention of data breaches. As such, robust mobile app security is essential.

One of the most effective security technologies you can implement is mobile payment tokenization. In this article, we explain what tokenization is and how it works.

What is Mobile Payment Tokenization?

Mobile payment tokenization is the act of replacing sensitive data, like the PAN (Primary account number), with tokens. Tokens is the term for useless data that can be mapped to the original data and 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.

Tokenization in Action

Here are some examples of how the world's most popular mobile wallets use tokenization technology to improve security.

Wallet

Tokenization

WeChat

No indication of Credit Card Tokenization. Cards are saved in “safe” PCI-DSS databases.

A token ID is used to identify the user online and retrieve the credit card data. However, this is not credit card tokenization.

Alipay

No indication of Credit Card Tokenization. This is more or less the same system as WeChat. Tokenization via access token.

Apple Pay

Credit Card Tokenization. The PAN is replaced by the Device Account Number (DAN), an Apple Pay-specific token. 

Google Pay

Credit Card Tokenization. The PAN is replaced by a “virtual account number.”

Wal-Mart Pay

No Tokenization. Cloud-based.

Samsung Pay

Host Card Emulation (HCE) and Credit Card Tokenization (DPAN).

PayPal One Touch

Apparently uses Credit Card Tokenization. PayPal has been using Credit Card Tokenization for a long time with its web version.

Zelle

Tokenization.

Venmo

Venmo is a cardholder-side multi-merchant tokenization system.

Square Cash

Tokenization.

Amazon Pay

Tokenization.

Visa Pay

Host Card Emulation (HCE) and Credit Card Tokenization.

Starbucks Pay

No Credit Card Tokenization. Cloud-based.

 

Most, if not all mobile payments use some form of tokenization with access tokens, even if they don't explicitly use credit card tokenization where the user:

  • Authenticates themselves using a 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 use "high-value” tokens that in lieu of credit card data to place transactions, while others don't. 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 Payment 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.

Download white paper

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.

Interestingly, the DPAN has its own expiration date and it acts as a “super-credit card” because it is not linked to the original credit card data, but to the FPAN, the Funding Primary Account Number. So, even if the card has to be renewed, there is no need to change the DPAN.

Yet, the DPAN cannot be used by an attacker without the cryptogram and other Samsung Pay data. For instance, it is totally useless for any CPN (Card-Not-Present) fraud.

The cryptogram sent with the DPAN and the transaction information is generated by a cryptographic key contained in the Samsung Phone’s TEE (trusted execution environment). The cryptogram also contains a counter (ATC) to prevent replay attacks in a design similar to EMV.

It is an interesting aspect that the Knox™ secure platform used by Samsung has several certifications, including Common Criteria, FIPS, and DoD. This makes Samsung Pay a true rival of EMV, but with the advantage of using “native” credit card tokenization.

The following example presents a typical workflow in Samsung Pay:

  • Initially, the cardholder enrolls his card to a TSP that is designated by the card issuer.
  • A token, the DPAN is generated in the card vault of the TSP and securely sent to the Samsung device where it will be stored.
  • When the cardholder performs a transaction, the token, the payment information, and the cryptogram are sent to the payment network through the acquirer. The token is unmapped and the real PAN, in fact, the PFAN is sent back to the payment network, which will ask the issuer bank to charge the account. 
  • During the workflow, the cryptogram is authenticated as a proof of the validity and authenticity of the transaction request. 
  • The authorization is eventually sent back to the merchant. 

Tokenization-Process-Infographic

Samsung Sets the Standard

As you can see, well-thought-out credit card tokenization is an essential part of Samsung Pay security. Even if the phone (quite secure in itself) is hacked, only useless information would be leaked. 

Mobile payment tokenization is almost a de facto standard. It's conceivable to imagine that mobile payment applications won’t be allowed to operate in the near future without a solid tokenization solution in place. 


 

Read White Paper

References and Further Reading

  • Read more articles about Runtime Application Self-Protection (RASP) for mobile banking applications (2018 - today), by Martin Rupp, Stefan Hansen and more
  • More articles on Crypto Service Gateway (2018 - today), by Chris Allen, Jo Lintzen, Terry Allen, Rob Stubbs, Stefan Hansen, Martin Rupp, and more.