It is no secret that electronic payments have revolutionized everything we have known as traditional commerce. This new era of e-commerce simultaneously satisfies both consumer craving for fresh marketplaces as well as convenience… both in person and online… in record time… on a global scale.
Along with this new way of conducting business electronically, there are also new words, acronyms, and even laws that govern how businesses maintain ethical standards of practice for payment processing. The understanding of tokenization is where we are headed, but to fully appreciate the benefits of tokenization, one must first understand the dangerous problems it has solved.
As the front doors fly open to trillions of dollars flowing throughout the world electronically, hackers are secretly working hard to break in through the back doors. Of course, the goal of these backdoor thieves is to tap into the vast stream of money by stealing credit card information, but the more sophisticated heisters have their eye on the most valuable diamond in the case, which is to gain private information in a readable form to sell, duplicate, or even exploit the consumers themselves.
Small organizations can be easy targets to steal cardholder data (CHD) from, but as recent headlines prove, the skill set and patience of the hacker are the only real discriminations in the world of hacking success. The “big fish” such as large retailers, hotel chains, and websites with millions of users have also been targeted and successfully breached in recent years.
To the consumers, the benefit of convenience certainly does not outweigh the risk of a data breach… or does it? Despite the recent hacks, the raging economy of e-commerce is unstoppable, largely due to consumers being somewhat protected against monetary theft. If, for example, a debit or credit card number is hacked or stolen, and then used to make a purchase, the consumer's account is quickly refunded once a report has been filed.
Refunds may satisfy consumers, but there are still two looming questions that must be answered: who is going to pay, and how much data was stolen?
Who is going to pay? The answer is simple to the issuing bank or credit card provider: the retailer. In the end, it is the retailers who are responsible for keeping a consumer's data secure, so they must make good on the purchase if there is a breach. This is called a chargeback. Chargebacks are expensive to the retailer, and they are still out the stolen goods.
Chargebacks are also very stressful, because retailers know the larger diamond will always be personal data, which can take years to be fully realized. What type data was stolen? How many customers were affected? These two giant elephants in the room leave companies scrambling to secure ever-changing technology to protect themselves, while keeping transactions simple, fast, and convenient for the consumers.
As the need for electronic payment and data processing grows, so must the trustworthiness of the security systems put in place to protect against identity theft and data breaches. After all, being hacked is not a result of a company’s conscious willingness to divulge its customers’ valuable information, but rather the result of an overlooked, insufficient, or outdated security measure that is simply surpassed by hacker technology. It’s no wonder that identity theft has quickly become more lucrative than ever before. It’s a big, fast-moving problem that requires an ingenious solution that will keep private data safely ahead of the curve and untouchable to hackers.
One of the first and original lines of defense that companies and consumers have used against hacking is called encryption. Encryption can be as simple as a password to protect a computer, cell phone, email, or document. The longer a password is, the more protected the device or data is. This type of security can be a fairly basic breach from a hacking standpoint.
Taking the encryption up a security level is a mathematically generated “secret code.” Just as codes have been used in the past for secret message delivery where only the recipient has the key to decipher the message, so it goes with electronically encrypted data. The data is encrypted into unreadable characters by the sender’s key, and then decrypted by the receiver’s key. The sender and receiver can share the same “code key” to lock the data and re-open it. This form of encryption definitely makes it harder to hack, but if the code key falls into the wrong hands on either the sending or receiving end, the hacker can easily gain access to the data stored within.
An even higher form of encryption security is when the sender and receiver each have a unique key that will only lock, or only open the data. In this case, a hacker would need to have both keys in order to crack the code into usable data, and having to find both keys is definitely harder than having to find only one.
Whenever a transaction takes place, encrypted data is sent from the retailer to the payment processor through the internet. After the transaction, no matter the encryption style hiding it, the data still remains, potentially sparkling at hackers wherever it is stored. If the data were to remain in a retailer's system once a credit card payment had been processed, it would be up to each retailer to determine how much security was enough. To some, a simple password seems like plenty, especially when the latest security software is outside of their budget. To others, encrypting the data plus a computer password would be a proactive approach.
To "help" minimize the risk to retailers who accept credit card payments, it is mandated that they not store the data locally, but rather on a server deemed up to the task, and protect the information as it is being transmitted to the secure server, as defined by the Payment Card Industry Data Security Standard, or PCI DSS. Hosting data on a PCI-compliant server seems like a great solution because, after all, the best kind of security for a retailer's system is when the data doesn't exist at all. The retailer still needs to take steps to be PCI compliant, though, as the data is still being transmitted to the place of storage.
As good as everyone's intentions are in adhering to or enforcement of security laws, any server can be vulnerable to hacking, because the encryption code is based on what's called an algorithm, which means a mathematical pattern created the encryption.
The word "algorithm" is basically a fancy word for systematically solving problems using step-by-step procedures. Sounds pretty complex, but a common example of an algorithm points to the concept of following a simple cooking recipe.
When following a recipe, an algorithm of ingredients is being followed to create the dish. There may be some instructions mixed in, but it is a system of adding ingredients in a specific order to create a final "encryption," or "Mom's Casserole," or whatever is being cooked.
While the recipe example is great for explaining what an algorithm is, it may not be the best example to explain from a hacking standpoint, but will give a general picture. To hack "Mom's Casserole" recipe would be a painstaking, scientific process where instruments and a sample are used. Using scientific measures, diagnostics would be run on the sample to figure out Mom's secret ingredients based on data of known foods and their scientific breakdown.
The time it takes for the diagnostics to be run may be an analogy of how a hacker would spend time running their program on an encrypted file, but without being a hacker, it's almost impossible to know exactly how this is accomplished, or how big of a sample is needed.
What is known, and what is important to know, is that hackers do manage to crack very complex mathematically-generated encryptions, making encryption by itself a possible recipe... for disaster.
With that said, encryption has been around for a long time, and has been a great solution over the years. The key to success with encryption is managing it well. It's still being used today, and isn't going anywhere... but... what if there was a way to encrypt data that was not a mathematically generated algorithm? What if no primary account numbers (PAN) or cardholder data (CHD) would have to be transmitted from the retailer while processing a payment? What if the "encryption" process could generate a secret code based on utter randomness? It sounds like a crazy, philosophical idea, but this is what tokenization has accomplished, except that tokenization takes encryption a million steps further than that: there are no keys, either.
The absence of keys is not because no keys are needed to open the protected data, but rather there is simply no data left on the retailer's computer to protect; in fact, this private data never even touched the retailer's system, saving them from mountains of potential liability and simplifying PCI compliance issues. Tokenization is revolutionary for many reasons, and doesn't stop at payment processing. The world of personal and medical data also utilizes the benefits of tokenization's security. It's big.
From the payment processing standpoint, the retailer, which could be a store, cell phone app, website, or anyone who accepts a digital payment, can directly integrate tokenization into their POS system so everything is automatic and simple. When a customer swipes a card, the information is sent to what's called a token vault. This ingenious form of communication, the token vault, is where the consumer shares their cardholder data, rather than with the retailer. Retailers can finally relax, because they never have to store the cardholder's account number or other personal information associated with it.
Once a card is swiped or entered, the token vault sends the card number along with the token to the issuing bank, who issues approval for the charge. From there, it's all token. The long string of randomly generated letters, numbers, and symbols, has BECOME the one-time credit card number without storing any cardholder data, and this new token is useless on its own.
Because there is zero connection between the customer's card number embedded in the token, the token can be set up for recurring charges, making it a secure way for retailers to offer subscription services.
The token vault is a chosen service, and there are several "token makers" to choose from. When choosing a token service provider (TSP), it's important to make sure the vault company is not merely encrypting the card numbers and calling them tokens. To be a real token vault, it must be randomly generating the card numbers.
Tokenization has not been without growing pains, as the vaults can get overloaded, creating glitches and speed issues; however, this technology has proven to be reliable, secure, and convenient.
Tokenization is here to stay, and payment processing is just the beginning of what this ingenious security solution can, and will, offer the future.