Fintech

Regaining Customer Confidence with Payment Tokenization Technology

In 2013, Target announced that hackers breached 40 million card accounts, affecting more than 70 million customers. Ultimately, the retail mammoth would rack up $162 million in related expenses, including setting a $10 million class-action lawsuit for letting it happen.

2014 brought more bad news for the retail industry when Home Depot announced an even greater breach, with 56 million customers affected. A breach of eBay accounts left 145 million customers resetting their passwords.

The trend continued into 2015 when both Trump and Hilton hotels reported theft of customers’ credit card information.

While these examples do not justify a total loss of confidence in cashless transactions, you could say there is a problem. With the number of credit card purchases projected to increase an average of 16% worldwide by 2018, compared with 2012, the payment processing industry needs more than Fraud Prevention 2.0, it needs a game changer. Many stakeholders are betting that a technology called tokenization will tilt the score in their favor.

What Tokenization is and How It Works

Payment tokenization protects against fraud by removing from the payment transaction the thing criminals want most: account numbers. Rather than retailers storing customer Primary Account Numbers (PAN) in their Point-of-Sale (POS) systems, with tokenization they only store a randomly-generated number, called a token.

The token is generated by either the issuer or a third-party tokenization service. In either case, the customer’s account information is stored in a special database called a token vault, located at the tokenization service or issuer, where it is paired with the encrypted account information. The token is returned to the merchant, along with the credit authorization response, and is stored in their POS. Once the token has been set, all future transactions will send the token, rather than the PAN, to the processor.

The primary appeal of tokenization is that it improves data security by eliminating the need for merchants to store customers’ account information, reducing fraud potential and PCI-DDS requirements.

Why is it important?

The payments processing industry is undergoing a revolution. It has to. Prudent stakeholders are seeking opportunities to improve data security and to ease the customer payment experience at the same time. Despite a growing list of emerging and improved data security technologies, tokenization appears to be an indispensable component, regardless of whatever technologies may prevail.

If tokenization is to become the de facto card security standard, it must not only be effective and ease the customer’s experience, it must also be flexible. Luckily, tokens play well with others. Cross-platform compatibility has given tokenization a seat at the table with digital wallets, including Apple Pay, Samsung Pay, and Android Pay.

The true test of robustness for any technology is its ability to integrate with merging technologies. As an example of mobile payment tokenization’s flexibility, it pairs perfectly with Near Field Communications (NFC), which enables customers to affect payment transactions simply by bringing their mobile device within close proximity of a NFC-enabled POS. QR codes stored on the phone and Bluetooth offer alternatives to NFC, each with its own advantages and disadvantages.

Effectiveness, ease of customer experience, flexibility, and seamless integration into emerging technologies… with a resume like that, tokenization is becoming hard to ignore.

The Evolution of Payment Security

Modern payment security started with IBM’s invention, the magnetic stripe, which American Express added to its cards in 1970. A decade later, Visa and MasterCard did the same. Storing account information on a magnetic stripe allowed customers to perform banking transactions without going into the bank and by using another IBM marvel, the ATM machine. While stripes offered much greater security than the zip-zap card reader, which allowed merchants to make a carbon copy of the customer’s card and offered little security, they eventually became vulnerable to replication by technologically savvy identity thieves.

In 1984, the European Council for Payment Systems adopted a new security standard known as the smartcard, or EMV (Europay, MasterCard, Visa). The new chip-on-a-card technology was an advancement over mag stripes, but required cards to be inserted or “dipped” into the card reader. For each transaction, data was read from and written to the card. The process was slower than swiping mag stripes, but reduced card fraud significantly. By 1992, all European markets used EMV-enabled cards; only American financial institutions continued issuing stripe cards. With the emergence of NFC in the payment space, new chip-enabled cards facilitate payments by simply holding them next to the card POS terminal.

For either contact or contactless EMV cards, tokenization provides a security layer between account data and those who would steal it. With the mag stripe quickly giving way to EMV cards in the U.S. one would expect to see a decline in card fraud there, also.

Encryption vs. Tokenization

Encryption uses algorithms to convert account data into a code that cannot easily be read. A special code or password, called the key, is necessary to decrypt the data back into its original readable form.

Even though tokens are of no value to criminals, best practices dictate the encryption of all data included in a payment transaction. End-to-end encryption protects data en route to the tokenization service, to the card issuer (if not the same), and back to the POS or secure element. While tokenization replaces sensitive data with data that has no inherent value, encryption protects data throughout its entire lifecycle – while in transport and when at rest in a secure database.

Tokenization in Mobile Payment Processing

Mobile payment processing poses both opportunities and challenges. The ability to pay for a purchase by waiving your phone over the POS terminal may be convenient, but making sure your mobile device doesn’t reveal your account information to criminals requires serious technology.

To keep sensitive data safe while stored on mobile devices, industry standards require that such information be stored in a secure element. The secure element includes hardware and software needed to securely store and administer sensitive data.

HCE and Tokenization

While secure elements once represented the industry’s best effort at keeping data safe on mobile devices, the mobile platform simply isn’t the most secure place to store valuable information. The solution is Host Card Emulation (HCE). HCE allows card data to be stored on secure servers in the cloud, rather than on a mobile device. Both Blackberry, the creator of HCE, and Android 4.4 both utilize HCE, while Apple uses its own rival digital wallet solution, Apple Pay, for cloud-based mobile payments.

Without the secure element on the mobile device, customer information could be vulnerable to breaching. The solution? You’ve got it – cloud tokenization. Once, again, tokens become very valuable in keeping transaction data virtually worthless.

How Ignite can help?

With Ignite’s offshore outsourcing services, you have a dedicated team of professional developers with the skills and experience to develop your tokenization-based solutions. We specialize in the development of payment platforms that use advanced tokenization technology.

With the complexity of today’s payment technology, off-the-shelf solutions simply will not do. You need a partner capable of creating the custom payment tokenization solutions that will create growth, not headlines.

Whether you need to upgrade your payment gateway to accept online payment tokenization, or a complete online banking solution, look no further. We have the expertise to implement tokenized solutions built on the latest technology, methods, and standards.

For more information, contact us at igniteoutsourcing.com.

Leave a Reply

Your email address will not be published. Required fields are marked *