( image : Wikipedia )
Reserve Bank of India (RBI) recently extended the deadline set for debit & credit card tokenisation by 3 months to Sep 30. Some of the reasons to extend the deadlines are a) lack of public awareness, b) technical preparedness & c) implementation of alternate mechanism to handle all post-transaction activities such as charge back & settlement related to guest checkouts.
To understand Card on File Tokenisation (CoFT), I referred through SBI FAQs & an explainer by Razorpay . RBI also has published a FAQ here .
Primary account numbers (PANs) are the 16-digit numbers found on every credit or debit card. A card’s PAN is widely accepted across businesses, making it easy to transact online. However, this also makes PANs valuable to bad actors to use for fraudulent purchases, leaving consumers vulnerable to stolen cards and businesses to data breaches
In effect Tokenization is the process of replacing a card’s 16-digit number on the plastic card with an alternate card number, or ‘Token’ which shall be unique for a combination of card, token requestor and device.
Tokens can be used for online transactions, mobile point-of-sale transactions or in-app transactions. The token will not contain any personal information that can be directly accessed and will keep changing making it more secure.
RBI has recommended that businesses, payment aggregators, payment gateways and acquiring banks in the payment ecosystem – particularly payment service providers – use and store ‘tokens’ instead of card information through tokenisation.
Tokenisation and de-tokenisation will be performed only by the authorized card network and recovery of original PAN should be feasible for the authorized card network ( e.g. Mastercard, Visa, Rupay ) only. Adequate safeguards will also be put in place to ensure that PAN cannot be found out from the token and vice versa, by anyone except the card network.
Tokenisation and de-tokenisation requests will be logged by the card network and available for retrieval, if required Actual card data, token and other relevant details shall be stored in a secure mode. Token requestors (merchant sites) will not store PAN or any other card detail.
Only the last 4 digits of the customer card, along with Issuer Bank name and card network can be available to a merchant during transactions . Hence, a tokenized card transaction is considered safer as the actual card details will not be shared / stored with the merchants to perform the transaction.
To create a token, one would have to follow the instructions specified by the online Merchant and complete the registration and verification flow .Generally, the process would entail filing your card details, followed by verification via OTP and then a token will be generated associated with your card. This token will be saved by the online Merchant.
If you do not choose to tokenize your card then you will have to enter all your card details including card number, expiry and CVV for every payment you make.
Once a token registered on one merchant site it cannot be used on another merchant. Each merchant will have a unique token associated with every card saved on that Merchant. This token cannot be used for any other card that you might have or on any other merchant. Essentially, your card will have multiple tokens based on the number of Merchant you would have tokenized your card with.
You can delete token by directly going to the merchant’s website/app and deleting the card associated with the token from your payment preferences. You can request for tokenisation of any number of cards to perform a transaction.
The relationship between token and card-related data is saved in a vault owned by the card networks. As a result, customer card details will be safer & help prevent online frauds.