loader image
Secure Online Payment Processing Concept - Making Secure Payment

Tokenization: Creating a stir in the Payments Industry

In today’s world, increasing online frauds and cyberattacks are causing security and trust issues among the general public in the adoption of digital payments, and these data security issues have become a major concern for online service providers. The service provider has been looking into ways to reduce this risk. One such solution is “Tokenization,” a new buzzword in the payments industry. Tokenization adds an extra layer of security to users’ sensitive data and prevents online and digital data breaches.


The concept of digital tokenization is inspired by the concept of physical tokenization, which has existed since the invention of currency. Token coins replace actual coins or banknotes in physical tokenization. These token coins have a real identity and value, but they only have meaning in a limited and controlled space. For example, casino tokens have no value outside of the casino’s premises.


The payments card industry is using digital tokenization to protect users’ sensitive data and provide better customer assurance in order to increase their trust. It is a low-cost and simple-to-implement solution for merchants.


What is Tokenization?


Tokenization is the process of encrypting sensitive data by replacing it with an unreadable token. The tokens can then be passed through the internet or the various wireless networks required to process the payment without exposing actual bank details. The actual bank account number is kept secure in a token vault.


Tokenization is commonly used to combat credit card fraud. It relieves merchants of the burden of storing sensitive card data of users, reducing the work and effort required to be PCI DSS compliant.


How does it work?


A customer makes an online purchase through an e-commerce website or offline through a merchant POS and then chooses a credit card payment method. The customer enters sensitive data on the portal, such as card number, CVV and cardholder name or enters a PIN on the POS machine. The card data collected is stored on the tokenization server rather than the e-commerce website server. The tokenization server processes the card data, stores the original card data on the Secure token server and generates a token of the same length from a random alphanumeric string. The token is then forwarded to the merchant’s acquiring bank. The acquiring bank sends the token to the card network, which processes it and shares card details with the issuing bank for payment authentication. Payment is completed when the issuing bank responds to the card network. The Card Network is the only entity that can read the token.


Tokenization Vs Encryption 


Data encryption and tokenization are similar in the sense that they both replace original data with a random code, but they are vastly different in terms of ciphering mechanism. 

Sensitive data is mathematically changed into a new code in data encryption, but the original data can be deciphered with the appropriate key. However, because there is no relationship between the token generated and the original data, the token cannot be reversed in the case of tokenization. Even if hackers obtain the token details, they will be unable to retrieve original data from that information, rendering the token meaningless and useless to them.

Tokenization is widely used by the payments industry across the globe due to its data security offering. Furthermore, it provides the following benefits to all stakeholders involved in the transactions. 

  • Customers can develop trust in online transactions as the likelihood of theft or leakage of sensitive data decreases significantly.
  • The merchant, acquirer and processor do not need to be concerned about the user’s sensitive data being compromised even in the event of a cyberattack because they do not store any such information. 
  • Merchants can provide a trusted and secure payment environment for their customers without obtaining PCI DSS certification, saving them the cost of such certification.
  • Tokenization of payments creates a safe and secure environment for users, merchants, payment gateways, financial institutions and regulatory bodies.

Tokenization is currently only available with Networks in India. Issuers must still evolve to make this a reality. 


The RBI issued a directive in 2020 stating that merchant payment aggregators and payment gateways could no longer store card credentials. To increase cardholder safety, RBI guidelines require a full-time shift, which is why tokenization must be implemented. And now there will be a plan in place for every issuer, merchant and network to implement this.

Learn More

PCI DSS: The standard for card security

Buoyed by the festival season euphoria, credit card transactions for the first time crossed INR 1 Lakh Crore in October 2021 and debit card transactions were upwards of INR 7.5 Lakh Crore during the same period. With such exponential growth in cashless payments, information security and privacy of cardholder data is of utmost importance. Ever wondered how it is managed? What are the guidelines regarding data security for card based transactions? How does an entity comply with these guidelines? That’s where PCI DSS requirements come into play. 


So what is PCI DSS? Who formed these standards? What requirements does it prescribe? And who is responsible for adherence to these requirements? We will respond to these questions below:


The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards designed to ensure that all companies that accept, process, store or transmit card information maintain a secure environment for processing transactions. PCI DSS was developed to encourage and enhance cardholder data security, as well as to facilitate the global adoption of consistent data security measures. Payment Card Industry Security Standard Council (PCI SSC), an independent body created by Visa, MasterCard, American Express, Discover and JCB to standardise and improve account security throughout the transaction process, launched PCI DSS in September 2006; the latest version was debuted in May 2018.

PCI DSS applies to all payment card processing entities, including merchants, processors, acquirers, issuers and service providers. It also applies to any other entity that stores, processes or transmits cardholder data or sensitive authentication data.


12 Standards of PCI DSS


PCI DSS specifies 12 standards to which all entities must adhere. The following is an overview of these standards:


Objective Standard
Build and Maintain a Secure Network and Systems 1. Configure and maintain a firewall to protect cardholder data

2. Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data 3. Protect Stored Cardholder Data

4. Encrypt Transmission of Cardholder Data across open, public networks

Maintain a Vulnerability Management Program 5. Protect all systems against malware and update anti-virus software or programs on a regular basis

6. Develop and maintain secure systems and applications

Implement Strong Access Control Measures 7. Restrict access to cardholder data by business need to know 

8. Identify and authenticate system component access

9. Restrict physical access to cardholder data

Regularly Monitor and Test Networks  10. Track and monitor all network resource and cardholder data access

11. Test security systems and processes on a regular basis

Maintain an Information Security Policy  12. Maintain an information security policy for all personnel


Let’s delve deeper into each standard to better understand the goal:


Install and maintain a firewall configuration to protect cardholder data

A firewall is a network security system that monitors and controls network traffic, both incoming and outgoing. Firewalls prevent foreign or unknown entities from accessing private data. These anti-hacking systems are frequently the first line of defence against hackers. Because of their effectiveness in preventing unauthorised access, firewalls are required for PCI DSS compliance.


PCI SSC provides a detailed step-by-step process for configuring and maintaining a firewall.



Do not use vendor-supplied defaults for system passwords and other security parameters

 Routers, modems, POS systems and other third-party products frequently include generic passwords and security measures that are easily accessible to the general public. Businesses frequently fail to secure these vulnerabilities. Before installing a system on a network, businesses must change the vendor-supplied default passwords and remove or disable any unnecessary default accounts.


Keeping a list of all devices and software that require a password is one way to ensure compliance in this area (or other security to access). In addition to a device/password inventory, basic precautions and configurations should be carried out on a regular basis. (For example, changing the password). 


Protect Stored Cardholder Data

The third PCI DSS compliance requirement is two-way data protection for cardholders. Cardholder data protection methods such as encryption, truncation, masking and hashing are critical components. If an intruder gets around other security measures and gains access to encrypted data, the data is unreadable and unusable to that person without the proper cryptographic keys.


The PCI SSC recommends that entities implement data retention and disposal policies to keep cardholder data storage to a minimum. It also requires entities not to store the card verification code or value (a three- or four-digit number printed on the front or back of a payment card that is used to verify card-not-present transactions) after authorization. That is why CVC/CVV is required to be entered by the customer every time an online transaction is made.

Furthermore, when PAN (Permanent Account Number or Card Number) is displayed, entities must mask it (the first six and last four digits are the maximum number of digits to be displayed), so that only personnel with a legitimate business need can see more than the first six/last four digits of the PAN.


To further prevent entities from storing cardholder data, the RBI has mandated tokenization for all card-based transactions. No entity in the card transaction / payment chain, other than card issuers and / or card networks, shall store the actual card data beginning January 1, 2022.



Encrypt Transmission of Cardholder data across open, public networks

Cardholder data is transmitted via multiple channels (i.e., payment processors, home office from local stores, etc). Malicious individuals continue to target misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols in order to gain privileged access to cardholder data environments. When this data is transmitted over networks, it must be encrypted. PCI SSC defines cryptographic algorithms, keys and certificates for use in encryption.


Protect all systems against malware and regularly update anti-virus software or programs

Malicious software, also known as “malware,” including viruses, worms and Trojans, enters the network through a variety of business-approved activities such as employee e-mail and Internet use on mobile computers and storage devices, resulting in the exploitation of system vulnerabilities. To protect systems from current and evolving malicious software threats, antivirus software must be installed on all systems that are commonly infected by malware. Furthermore, all antivirus software must be updated on a regular basis, and an audit log must be kept.



Develop and maintain secure systems and applications

To protect against the exploitation and compromise of cardholder data by malicious individuals and software, all systems must have all necessary software patches. All software and applications must be updated on a regular basis with security patches to address system vulnerabilities.



Restrict access to cardholder data by business need to know 

To ensure that only authorised personnel have access to critical data, systems and processes must be in place to limit access based on need to know and job responsibilities. All employees, executives and third parties who do not require access to this information should not have it. The roles that require sensitive data should be well-documented and updated on a regular basis.



Identify and authenticate access to system components

 Individuals with access to cardholder data should have their own credentials and identification. For example, there should not be a single login to the encrypted data with multiple employees having access to the username and password. By assigning a unique identification (ID) to each person with access, you ensure that each individual is held individually accountable for their actions. When such accountability is in place, critical data and system actions can be traced back to known and authorised users and processes. In the event that data is compromised, unique IDs reduce vulnerability and speed up response time.



Restrict physical access to cardholder data

Any cardholder information must be physically stored in a secure location. Data that is physically written or typed, as well as data that is stored digitally (e.g., on a hard drive), should be kept in a secure room, drawer or cabinet. Not only should access be restricted, but any time sensitive data is accessed, a log should be kept to ensure compliance.


Track and monitor all access to network resources and cardholder data

Logging mechanisms and the ability to track user activities are critical in preventing, detecting and mitigating the effects of a data breach. When something goes wrong, the presence of logs in all environments allows for thorough tracking, alerting and analysis. Without system activity logs, determining the cause of a compromise is extremely difficult, if not impossible.



Regularly test security systems and processes

All ten of the preceding compliance standards involve a variety of software products, physical locations, and, most likely, a few employees. Many things can break down, become out of date or suffer from human error. These threats can be mitigated by complying with the PCI DSS requirement for regular system and process scans and vulnerability testing.


To ensure that security controls continue to reflect a changing environment, system components, processes and custom software should be tested on a regular basis.


Maintain a policy that addresses information security for all personnel

For compliance, an inventory of equipment, software and employees with access must be documented. Access to cardholder data logs will also necessitate documentation. The flow of information into a company, where it is stored and how it is used after the point of sale must all be documented. 

A strong security policy establishes the security tone for the entire organisation and informs employees of what is expected of them.


Levels of PCI DSS

In addition to adhering to these standards, organisations must assess and submit a Report on Compliance (RoC) based on the number of transactions handled each year:

  • Level 1: Merchants who process more than 60 Lakh card transactions per year
  • Level 2: Merchants who process 10 Lakh to 60 Lakh transactions per year
  • Level 3: Merchants who process between 20,000 and 10 Lakh transactions per year
  • Level 4: Merchants with fewer than 20,000 transactions per year

The assessment for Level 1 merchants should include an external audit performed by a QSA (Qualified Security Assessor) or ISA (Internal Security Assessor). They will conduct an on-site evaluation of the organisation in order to:

  • Validate the scope of the assessment
  • Review your documentation and technical information
  • Determine whether the PCI DSS requirements are being met
  • Provide support and guidance during the compliance process
  • Evaluate compensating controls


To demonstrate compliance, the auditor will then submit a RoC to the organization’s acquiring banks. 

To confirm compliance with PCI DSS requirements, Level 2 merchants must only submit a self-assessment questionnaire (SAQ) and a self declared ROC rather than an external audit.

Level 3 and 4 merchants are only required to fill out a self-assessment questionnaire (SAQ).


Benefits of PCI DSS Compliance


At the very least, complying with PCI Security Standards appears to be a daunting task. The tangle of standards and issues appears to be too much for even large organisations, let alone smaller businesses. However, compliance is becoming more important and may not be as difficult as one might think, especially with the right tools. The following are some of the advantages of being PCI DSS compliant:

  • Your systems are secure, and your customers can put their sensitive payment card information in your hands; trust breeds customer confidence and repeat businesses.
  • It prevents data breaches. Each PCI-compliant business represents a less valuable target for cybercriminals. They will not only have a much more difficult time hacking your network, but they will also not find the data they are looking for!
  • Comply with global data security standards. The PCI DSS regulations were initiated by five of the world’s leading credit organisations in order to provide consumers with a mandatory level of protection by ensuring that merchants meet minimum levels of security when they store, process, and transmit cardholder data. Obtaining PCI compliance allows you to join the ranks of other international businesses dedicated to data security and consumer protection.


Non-compliance with these standards will result in fines imposed by the networks on acquiring banks, which will then be passed on to the organisation in question. Repeated violations may result in the merchant’s ability to accept payments using their cards being revoked entirely.

Learn More