Solutions
Resources
Contact
Login

Fraud Prevention

  1. Resources
  2. Fraud Prevention
  3. Tokenization

Tokenization

Tokenization

Using Tokenization to Keep Cardholder Data Safe

Payment card tokenization is an increasingly popular tool merchant can use to help prevent fraud and eliminate other vulnerabilities.

Electronic transactions provide fraudsters more and more global opportunities to make invalid purchases using stolen information. But, even when payment card data is legitimate (which is true in the bulk of transactions), merchants gain the additional burden of keeping confidential payment information out of the hands of hackers. That means eCommerce merchants must not only put more fraud prevention tools in place, they’re also responsible for securing the data customers share with them.

Tokenization technology lets merchants substitute sensitive data for tokenized information. This stops fraudsters from taking advantage of personal data during—or after—a transaction.

Tokenization

[noun]tō ● kən ● uh ● zey ● shuhn

Tokenization refers to the process of protecting sensitive data by replacing it with a randomized placeholder number called a token.

In a transaction involving payment card tokenization, the cardholder’s primary account number (PAN) is exchanged for an algorithmically-generated token. All transaction details are tied to the token. As a result, you never transmit the actual account information, which protects it from exposure to hackers.

The token is tied to the real account number, of course, but that data remains secure in a tokenization “vault.” The vault maintains a guarded database able to match the tokens with the authentic card information when necessary.

To illustrate, assume a customer wants to make a purchase. Rather than transmitting actual data like the card number, though, a one-time-use token is transmitted instead (figure B below). Even if a hacker managed to somehow get all the other transaction information, they would still not be able to connect it to an account or cardholder.

In the majority of cases, it makes no difference to the merchant: as long as the bank okays the transaction, the merchant doesn’t need to know the real account number. At the same time, the issuer can always provide the account number if the merchant needs it for some reason (such as challenging a customer dispute).

It’s also important to note that these tokens are one-time-use only. Once transmitted, the token is no longer valid. So, even if a hacker manages to intercept transaction data, the information will be useless.

Hackers Are Only Part of the Problem.

The majority of your fraud may come from your customers. Click to learn more.

REQUEST A DEMO

Tokenization vs. Encryption

Tokenization is sometimes confused with another security protocol, end-to-end (E2EE) data encryption. The two are similar in some ways, but they are not the same thing. Each has its own peculiarities; from a security standpoint, though, the important distinction is that encryption can be mathematically reversed, exposing primary account number data under the right conditions.

Encrypted data uses a complex specialized algorithm combined with an encryption key. The key is necessary to translate (decrypt) the data back to its original state. Even though the data remains encrypted during transmission, fraudsters may be able to reverse the encryption with access to the key.

This limitation does not exist with tokenization, because tokens are irreversible. With tokenization, the cardholder’s personal information remains concealed at the merchant end of the transaction. Even if a criminal had a particular token, it would be impossible to reverse-engineer the information.

The “tokenization versus encryption” question isn’t necessarily an either/or matter. Merchants can take advantage of both end-to-end encryption and tokenization to achieve an even higher level of protection.

Other Benefits of Tokenization

Keeping cardholder information secure is the most important utility for tokenization technology. However, it does offer other merchant benefits.

PCI Compliance

The Payment Card Industry Data Security Standard (PCI-DSS) created strict security requirements for businesses dealing with customer financial data. Adhering to these guidelines creates a defense against data breaches and hackers.

Overall, this is a good thing. However, achieving and maintaining PCI-DSS compliance is a time-consuming and expensive task. Even worse, it doesn’t guarantee total protection for cardholders. Data breaches still occur, meaning merchants must find ways to supplement their PCI-DSS protection.

Tokenization can help in this regard. Using tokenization allows a merchant to lower the amount of customer card data kept in their internal systems. This reduces the scope of data susceptible to PCI-DSS compliance requirements and audits.

Fraud/False Declines

As we mentioned earlier, CNP merchants must remain wary of protecting themselves from fraudulent sales. Unfortunately, some efforts in this area can cause more issues than they solve.

False declines can result from overly-stringent fraud filter rules. And, because false declines are often an “invisible” problem, many merchants are woefully unaware of how many transactions—and possible sales—get declined in error.

A merchant using tokenization, however, requests tokens instead of account numbers. As a result, there are fewer factors involved for fraud filters to check. This has the potential to lower false declines.

At the same time, card network token systems such as Visa Token Service (VTS) and the Mastercard Digital Enablement Service (MDES) allow merchants to implement simplified checkouts for regular customers, decreasing declines (including false ones) and increasing cardholder loyalty.

Tokenization

Learn the #1 Chargeback Management Secret!

This detailed report shows why traditional attempts to combat chargebacks fail and how one fundamental misunderstanding is at the heart of most chargeback management mistakes.

Free Download

Cost

Many merchants prefer tokenization over end-to-end encryption because of the former’s lower cost. Because tokens are one-time-use, the merchant doesn’t have to pay to encrypt the data, decrypt it, and then re-encrypt it again.

In contrast, E2EE data is reversible. Since it can be returned to its original form, encrypted data is not considered as secure according to the PCI-DSS regulations we mentioned earlier. Even with encryption, maintaining compliance with PCI-DSS requirements demands additional security measures, meaning additional costs for the merchant.

Considerations When Implementing Tokenization

While tokenization is typically less expensive than encryption and less vulnerable to hacking, merchants should consider several other points before implementing tokenization technology:

  • Some internal procedures/scripts programmed using non-tokenized data may need to be updated. This could involve chargeback processes, Visa and Mastercard automated inquiry systems, third-party software, and more. Look for a tokenization vendor that offers as much security as possible, with the least IT investment.
  • Be certain the merchant retains ownership of the tokenized data in the event the business changes vendors or processors.
  • Additional products and support may be necessary to ensure cardholder information is not vulnerable during the short time period preceding authorization.
  • Be aware that tokenization is an all-or-nothing security measure. It can’t be implemented piecemeal.
  • Tokenization may cause confusion on the part of customers attempting to identify transactions via the account number. It may be necessary to educate customers in this area.
  • Tokens should consist of random numbers with no mathematical connection to the actual account. They should not be created using any algorithms or other predictable methods that could be reversed.
  • The token should have the same number of digits as the original card number.
  • The last four digits of the token should be the same as the credit card number.
  • To reduce the risk of a token number matching a real account number, tokens should not begin with the numbers associated with the major card networks (3, 4, 5, or 6).
  • Merchants need to be able to quickly exchange tokens for actual card information when chargebacks are issued. The representment window is extremely limited; merchants can’t afford to have dispute efforts slowed down by tokenized data.

Tokenization and Fraud: A Wider View

Another costly issue associated with tokenization is the mistaken belief that extra data security means decreased fraudulent activity. By and large, tokenization reduces security risks, but not fraud risks. Even with tokenization, merchants are still wide-open to unauthorized transactions and the accompanying chargebacks.

If you’d like to learn more about keeping both your data and your revenue safe, let us know. Chargebacks911® offers turnkey services designed to produce long-term, sustainable growth.

 

Prevent Chargebacks.

Fight Fraud.

Recover Revenue.

Embed code has been copied to clipboard