This year has seen two major changes related to card payments- first was the recurring payments framework which came into effect from October 1st, and now upcoming is the restriction on card data storage. Tokenisation was a suggested solution here, but an issue was that existing tokenisation norms, issued in 2019, only permitted device-based tokenisation (as seen in mobile apps like GPay, etc.). The permission for card-on-file tokenization (‘CoFT’), which came in September this year, was thus a very welcome development, allowing an industry-wide solution to the card data storage issue. The entire payments ecosystem, including card networks, merchants, payment aggregators (‘PAs’), banks and so on have thus been working on implementing this since then, to ensure a smoother transition by the implementation of the new norms by June 30th 2022.
What is tokenisation and why is it being implemented?
The restriction on storing card numbers was first introduced for merchants and PAs by the RBI PA norms in March 2020. The latest CoFT norms clarified that not only merchants and PAs but any players playing a role in the payments chain, apart from issuers, i.e., banks and card networks, can no longer store the actual card data.
Tokenisation as a solution here essentially replaces sensitive card information, i.e., the 16 digit card number, card expiry date and CVV with a unique and randomly generated ‘token’, a token expiry, and a cryptogram respectively. The token will be unique for the card number, token requestor (this can be the merchant/PA for eg.) and the merchant. Only card networks and issuers (banks) can act as a ‘token service provider’, i.e., the entity generating the token. The token itself comes with an expiry date, similar to the card expiry date; this may be 6 months to 3 years, as decided by the issuer. Lastly, for a given token based transaction, a cryptogram is generated with an expiry period (usually 24 hours), preventing the token from being reused post the cryptogram’s expiry, thus mimicking a dynamic CVV and adding an additional layer of security.
The reviewed payment flow using a token instead of card data will now look something like this:
Impact on related flows and finding solutions
The move is thus extremely customer friendly from a data security perspective, restricting both the circulation of actual card data in the ecosystem and the misuse of the token itself. The cryptogram for example, being transaction specific, prevents reuse of the token for a different transaction. In case of a breach moreover the token will also be traceable, to the merchant/token requestor that the token is unique to. Additionally, customer consent is required prior to tokenising the card data, which is taken via a tick box followed by an AFA that is normally combined with the transaction AFA.
Restricting card data storage nevertheless impacts a number of card payment related flows, for example, processes like refunds, chargebacks, recurring payments, etc. and facilities like EMI eligibility and BIN based offers at checkout. These processes normally depend on the information the card data provides. The card number or PAN for example reveals the name of the card network, issuing bank, card type (credit/debit card), card brand (platinum/gold), issuing country, etc. Implementing the restriction thus involves reworking all these processes to work without card data, and at a network wide level.
The last few months, the industry has thus been working on these. Solutions found here for example include:
● Refunds and chargebacks nowadays use new age solutions like instant refunds which are essentially a payout to the card, which now need to be reworked without the card data. In the meanwhile, refunds and chargebacks will simply return to the normal solution, which is a transaction reversal, working on the transaction ID instead, which is independent of the card data.
● Another example is BIN based offers (say a discount on a specific bank’s card). Earlier these worked via eligible BIN lists shared with merchants, now a solution for this is token-BIN mapping provided by card networks.
● For card based EMIs, files were shared earlier with banks containing the card numbers, for banks to convert a given card transaction to EMIs. For this, banks are now replacing these with new file formats requiring other identifying information like a transaction ID.
● Guest checkouts or card payments that aren’t based on saved card-on-file data were a concern initially, but now it is established that these are unimpacted.
What changes now for merchants and for their customers?
From a customer perspective, not much will change with the experience with making a tokenised card payment. The first time, they will need to enter their card details and opt to tokenise it via the checkbox, which will initiate the tokenisation and AFA process at the merchant’s end. Thereafter, once tokenised, customers will simply select their saved card as usual and make a card payment as usual.
From a merchant perspective, certain changes are required. The norms now only permit them to store the last 4 digits of the card for transaction tracking purposes. They will thus need to delete any saved card data by June 30th, 2022 (extended recently from January 1st), and adopt a compliant token service. Merchants can also choose between becoming token requestors themselves or integrating with a third party token requestor/ solution. An important point here is that these restrictions apply irrespective of the merchant being PCI-DSS compliant, which is an independent compliance obligation.
The move is thus extremely positive from a customer and data security perspective. With the recent extended deadline and with the entire ecosystem working towards a smooth transition to the new norms, hopefully disruptions will be minimised and a smooth customer experience with tokenised card payments will be possible.
The article is authored by Asheeta Regidi, Associate-Director, Policy, with inputs from Siddhesh Desai, Associate Product Manager and Yogesh Miglani, Senior Product Manager, at Cashfree Payments.