4 min read

Tokenization and Securing Mobile Payments Apps

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:


the mobile payment operator will use the token:


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.




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 getting the credit card data, however this is not credit card tokenization.


No indication of Credit Card Tokenization. More or less 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.


Tokenization is being used.


Venmo is a cardholder side multi-merchant tokenization system

Square Cash


Amazon Pay


Visa Pay

Host Card Emulation (HCE) and Credit Card Tokenization.

Starbucks Pay

No Credit Card Tokenization. Cloud-based.


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.

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. 


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) would be hacked, only useless information would be leaked. 

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


Read White Paper

References and Further Reading