Tokenization as a Method of Fraud Reduction
There’s an online security habit that was taught in the earliest days of ecommerce that many of us still practice to this day: to never, ever send out your credit card number over text or email. Even if you completely trust the recipient, the reasoning goes, you can’t be sure that their electronic communications won’t be hacked, intercepted, or otherwise compromised. Instead, we learned to only provide our credit card information through secure websites.
What constitutes a “secure” website, of course, is a question for the ages. One might judge a restaurant’s cleanliness by the state of its dining room, but a pristine table setting is no guarantee that the kitchen isn’t filthy. Likewise, a secure front-end connection—if you even have the technical ability to verify whether it’s secure or not—does not mean that credit card information will be handled with rigorous security protocols once the customer has transmitted it to the merchant.
With sophisticated, high-profile data breaches affecting even those merchants who make a good faith effort to secure their websites, assuring your customers that you’re doing your utmost to protect their information is more important than ever, but it’s also more challenging.
One possible solution is tokenization: turning sensitive data like credit card numbers into meaningless “token” numbers that can be linked to accounts by the card networks, but are unintelligible in their tokenized form to fraudsters and other observers.
Does it stand to reason, then, that merchants should adopt tokenization as a security measure if they haven’t already? To answer that, let’s take a closer look at how tokenization works and what steps merchants must take to implement it effectively.
Mobile payments are one of the main reasons tokenization has taken off recently. With more credit card numbers than ever being carried on wireless signals, it’s easy for fraudsters to “listen in” on unsecure transmissions.
Tokenization secures the transmission of sensitive data by replacing it with something that has no intrinsic meaning and cannot be decrypted. The only party that is able to associate the token with the cardholder’s personal account number would be the tokenization service provider, which could be the card network, a payment gateway, or a digital wallet platform like Google or Apple Pay.
Step by step, here’s how it works:
- The cardholder provides a credit card number to a merchant’s app or website that has tokenization enabled.
- The merchant obtains a unique token from their service provider and stores this token, not the PAN, in their computer system.
- When the cardholder makes a purchase, the merchant submits the token to their acquiring bank to process the transaction.
- The acquiring bank verifies with the tokenization service provider that the token matches a valid credit card.
- The transaction is processed without the cardholder’s PAN ever residing on the merchant’s server or being sent over the internet as part of a transaction.
If the merchant’s servers end up getting hacked, all the fraudsters will find is useless tokens, not any actual credit card information.
Tokenization vs Encryption
At first glance, it may seem like tokenization is just encryption with some new branding. While both processes serve the same objectives and bear some similarities, there are key differences.
The first and most important distinction is that encryption is reversible. Encrypted data is generated using complex algorithms. A mathematical “key” is required to decrypt the data into its original form, but with sufficient time and computing power, encryption can be reverse-engineered via a “brute force” approach—trying different decrypting algorithms over and over until success is achieved.
That means that the cardholder’s PAN is never displayed in its true form at the endpoint of the transaction, which is not necessarily the case with encrypted card numbers.
Are There Drawbacks to Tokenization?
Both encryption and tokenization help a merchant achieve PCI compliance by reducing customer data exposure, especially if those merchants have to store payment information for recurring transactions or one-click purchasing. It may appear as though tokenization is less vulnerable to hacking than encryption, and is therefore always the better choice, but there are some downsides to tokenization.
The biggest issue merchants tend to have with tokenization is interoperability—especially when they’re adding tokenization to an existing system. Scripts and procedures that may have relied on non-tokenized data to function will have to be identified and updated. In a large-scale legacy system, this can be a significant undertaking. Chargeback processes, card network inquiry systems, interchange management, and subsidiary security protocols may all be impacted.
Tokenization can also complicate customer service inquiries, when the cardholder attempts to use their credit card number to identify a transaction and the merchant does not have an easy way to match it to the corresponding token in their CRM system.
There are many good reasons to implement tokenization to secure your customers’ personal data. To use them effectively, however, merchants must make sure that their staff and systems are fully equipped to handle and process tokenized transactions.
There are a wide range of options for how tokens can be created, stored, and handled, more than we can fully cover in this space. It is important for merchants to choose a tokenization provider that can meet the specific needs of their business, industry, and customer base.
A successful, effective tokenization implementation will be holistic and through, not just a quick-and-dirty graft onto an existing system. Otherwise, there are too many potential points of friction that can lead to errors and inefficiencies—or worse, security breaches. Building a system in which tokenization is central, not incidental, is the best way to protect your customer’s data and your own reputation as a safe and secure place to do business.