<aside> 💫 Thanks to Ishan, Aparna, and the whole Juspay team for all the effort on this blog. One of the earliest features I worked on, as a designer and as a writer, has finally shipped!
</aside>
In 2015, the RBI mandated banks to phase out the magnetic strip payment cards and migrate them to EMV chip cards, which caused a big stir in offline transactions. Juspay believes the next big transformation is going to be Card Tokenization for online card payments. Both of these transformations share a common objective — preventing transaction frauds, online or offline.
The process of masking a customer’s PAN with a merchant scoped reference called Token is called Card Tokenization. Tokenization will strengthen security because card numbers will no longer need to pass through the various payment processing entities. The scoping of tokens to a merchant also reduces the risk and impact of fraudulent activity. Both online and offline transactions or NFCs can use tokens. For now, we will focus only on online transactions.
Tokenization can be done either at a Device level or on the server-side:
1. Device Side Tokenization
Device side tokenization binds tokens to a device. Meaning, the generated tokens can be used for repeat transactions only from that Device. Let’s say if a user tokenizes her card on Swiggy, then the generated token will be specific to that Device and Swiggy (merchant).
Payment solutions like Apple Pay or Google Pay (primarily app-based payment options) use Device side tokenization. For merchants to implement Device bound tokenization, a certified SDK provided by Networks or an approved 3rd party Token Requestor — TSP like Juspay is required.
2. Server-side or Card on File Tokenization (CoFT)
CoFT involves generating tokens that are not unique to any device — they are only mapped to the merchant. Meaning, a card tokenized on Swiggy is applicable across all Swiggy platforms (Desktop, Android, Mweb, etc.) And unlike Device side tokenization, CoFT can be implemented by integrating APIs provided by either: