Home > News and Blog

July 5, 2018
by David Goodale

What is Credit Card Tokenization?

Everything you need to know about tokenization and how it works.

Every business has security issues to consider when accepting credit card payments. The security considerations become more complex if you choose to store credit card numbers. Credit card tokenization helps to make it easier and more secure when storing credit card information.

In this article we'll explore what credit card tokenization is, how it works, and how it can help your business from both a cost and operational perspective.

What is credit card tokenization?

The term "Tokenization" may sound confusing but it's a fairly simple concept. It's to do with the storage of credit card numbers. More specifically, it refers to having a company store the credit card numbers for you, so that you don't have to store the sensitive data yourself.

A "token" refers to a credit card number that is being stored somewhere. Tokens can be stored by your credit card processor, or can be stored by a tokenization service provider such as Spreedly. To use it you will setup your website so that a 3rd party company will store the sensitive card information for you. Whenever you want to bill that card you just reference the token associated with that card. Your system will have no credit card numbers stored within it. Instead you'll have a list of token numbers (which isn't sensitive). Those token numbers can be used in place of a credit card number when submitting payments.

If that isn't quite making sense yet we should take a step back and consider the transaction flow.

How does tokenization work?

Tokenization often begins it's life as a normal regular credit card transaction. For a moment, consider a normal online purchase where you go to a website, add things to your cart, and then go to the checkout to pay. You will be asked to type in your credit card information. At this point it's the exact same as any online / e-commerce sale.

The differences start once the transaction is submitted. After the sale is completed you might want to store that card for future use, and this is where credit card tokenization begins.

In other situations you might not want to process a credit card upfront, but want to tokenize a card for other reasons. For example, you might be signing up for an online service in which the first month is free. In these cases the customer will type in their credit card number during the sign-up process to create a token that can be billed later. To do this you would submit a $0 transaction is processed which is often called a "verify request". Behind the scenes your payment processor will contact the issuing bank to ensure the card is valid, but no charge will be placed to the card.

Once a card is confirmed to be valid it can be tokenized. Regardless of whether it's being tokenized from a regular e-commerce sale, or if it's initiated from a verify request, the ultimate point is to get a response back from the card issuer to determine if the card is valid.

Once the credit card is confirmed a token will be created. The token is a number that is linked to that specific credit card. For clarity, the token number isn't a credit card number. It's just a reference number to that credit card. The company that is tokenizing your data (storing your credit card numbers) knows which token numbers refer to which credit cards.

Any time you want to bill that card in the future you can reference the token number. You've managed to store credit card numbers without actually having the sensitive information on your system!

Examples

It's important to clarify that there is more than one way to do tokenization. It's beyond the intended scope of this discussion to examine every possible way to set it up, but we will explore tokenization from an order, and also tokenizing with a verify request. Functionality can vary with different processors. For example, one difference is that some credit card processors will allow you to create a token from a previously processed order, even orders that were processed a long time ago. The functionality does differ between providers, so that is why understanding how tokenization works will provide a lot of clarity, and will help you to figure out the best way to implement it for your project.

Let's pretend that a merchant is selling a monthly newsletter that costs $100. On the 1st of each month all customers are charged $100 to their credit card.

Example 1 - Tokenizing a credit card that was previously processed.

• In some cases you may want to tokenize a credit card from an order that was already previously processed.
• In this example we'll start by billing the customer $100 for their first month of service. At this point it's just a regular credit card transaction.
• Your credit card service provider will process the transaction as normal. You get a regular authorization code (approval message) from the processor and send out the customer receipt.
• Although this was processed as a regular order we can still tokenize this data. Your website can respond back to your credit card processor after the approval:
• "Hey payment processor, a moment ago you processed a $100 sale. The authorization code was XYZ123. I want you to take the credit card associated with that order and tokenize it. I want you to call it token #50. Any time in the future, when I till you to bill token #50, I want you bill the credit card number associated with that order". (Obviously this is done programmatically, but that is how it works).

Example 2 - Tokenizing credit cards by using a verify request.

• With this method you will tokenize the credit card number at the beginning of the process.
• The new customer signs up for the newsletter.
• They enter their credit card number.
• The credit card number is sent with a verify request ($0). The card is confirmed to be a valid working credit card by the payment processor. A token is created that is linked to this credit card. For the purpose of this example we'll call it token #51.
• Now that you have a token, you can bill that card by referencing that token number. Your website can submit a transaction request: "Hey payment processor, please bill token #51 for $100.
• The customer is billed $100.
• At any point in the future you can bill this card again by referring to token #51.

In both of the above examples you've offloaded the sensitive information onto your service provider. That way you don't need to deal with the security issues yourself.

How does tokenization reduce the security burden on a business?

We have arrived at the topic of security. Without taking a deep dive into the topic of data retention and security, we can make a simple and obvious statement: one of the best ways to prevent credit card information from being stolen is to make sure you don't have it in the first place.

By tokenizing you can ensure that credit card information is not being stored in your system. It's not just a matter of good practice though, because there are industry rules around the retention of cardholder data. We are talking about the Payment Card Industry Data Security Standard (also known as PCI compliance).

How does PCI compliance factor into the use of credit card tokenization?

All merchants that process credit card transactions must be PCI DSS compliant. PCI DSS is short for the Payment Card Industry Data Security Standard.

PCI is a complex topic and is worthy of a series of dedicated articles. However, for the purpose of this discussion we can simply state that all merchants that process credit cards must be PCI compliant. Achieving compliance is made easier when you don't have credit card information stored.

The elimination of credit card numbers from your system is actually a recognized best practice as outlined in the PCI standard. There is simplified version of the PCI self assessment questionnaire, called SAQ A. SAQ A is specifically for merchants that do not touch or store any credit card information on their system. If you rely on a 3rd party company to touch and retain all the sensitive information then you qualify to complete SAQ A (so long as there are no other ways that your company touches or stores cardholder information). SAQ A is a lot easier to complete than the full assessment, and this is one of the main security advantages of using tokenization.

What type of business can benefit from tokenization?

A lot of people don't understand what type of business can benefit from tokenization. A few obvious examples will come to mind, but the appeal is a lot broader than you initially may expect. It's not just for businesses that do recurring billing. Let's look at some examples.

Obvious uses for tokenization:

• Web hosting merchants
• Gym memberships
• Subscription based businesses (such as Netflix)

Less obvious examples of businesses that see major benefits from tokenization:

• Garbage company (bill customer accounts each month based on how much garbage is picked up).
• A contractor (automatically collect the balance payment once construction is complete)
• Property rental company (collect rent monthly without needing to ask for credit card number)
• Accountant (automatically bill customers monthly based on the number of hours spent)
• An e-commerce website where you want to allow returning customers to purchase without re-entering credit card details.

The list can go on and on. Any company that will bill a customer more than once can benefit from tokenization.

Using tokenization has many benefits beyond just the security aspects. It makes administration easier. You don't need to wait for slow payers to make a payment. Instead you can do it yourself via the tokens, or even automate it so you don't need to do anything.

Lower Processing Costs - Reduced Interchange Savings for Recurring Transactions

Did you know that there is a major cost benefit to recurring billing transactions?

Most merchants have no idea that there is a significantly reduced processing cost for recurring transactions. Those cost savings will only be seen if you implement it properly. Follow this link to find the reduced Visa interchange rates and the MasterCard rates.

In Canada, interchange for recurring billing transactions is typically reduced by 0.15% to 0.55% depending on the card type, with some card types such as Mastercard World and World Elite seeing even more significant cost reductions. If you are a merchant and are processing recurring billing transactions it's important to flag them properly, first to realize the cost savings that the card brands provide, and second to increase the authorization rate (since recurring transactions are passed without the CVV code).

Recurring transaction rate comparison

To put it bluntly, you are literally giving away money if you are failing to properly flag transactions as recurring. You need to make sure your website is coded correctly (passing any special flags or requirements), and that your credit card processor (or your 3rd party tokenization service) is flagging the transactions properly so the reduced interchange rate is identified and passed back by Visa and MasterCard.

Another important note to make sure you see the cost savings is to make sure that you are getting interchange plus pricing from your payment processor. If you are not on an interchange plus pricing model your payment processor almost certainly won't pass on the savings. At Merchant-Accounts.ca we always recommend interchange plus pricing and will work with you to try to make sure your transactions qualify for the recurring billing interchange wherever possible.

Do all credit card processors provide tokenization?

Not all credit card processors support tokenization but many do. Even if your credit card processor does not support tokenization you can still use a 3rd party tokenization service provider such as Spreedly.

If you are looking for a credit card processor that offers tokenization one of the important criteria to consider is whether there is a cost associated with the tokenization service. Some credit card processors offer a free tokenization service, where others charge for the service. If your business has a small average ticket size (under $10/transaction) the cost of tokenization will become more important because a small per transaction cost can make a difference when you process small tickets. (a 10c cost added to a $5 sales = 2% cost increase). If you do larger tickets tokenization cost becomes less important.

If your credit card processor does not offer a tokenization service (or in some cases even if they do) you may want to consider using a 3rd party tokenization service provider such as Spreedly or HostedPCI. In the next section we'll explore options for using a 3rd party tokenization service.

Spreedly

Spreedly presents some interesting options because as the service has matured the tokenization capability has been combined with other complimentary benefits that fit hand-in-hand with the tokenization service itself. For example, since Spreedly fits in between your website and the payment processor, it means that Spreedly can redirect payments, as necessary, to other credit card processors. For example, if your website detects downtime at the payment processor, Spreedly can redirect those payments to your backup processor.

Spreedly works with over 120 payment gateways, which is a massive number of integrations. This gives access to many different payment processors in different regions and is a benefit that is especially valuable to mid-sized and larger merchants. This allows you to integrate your website with one service, but maintain a network of different payment processors. Although outside of the scope of this article, it means that you can build one integration but enjoy domestic interchange savings from Visa and MasterCard in a number of countries - major dollar savings in the thousands or tens of thousands of dollars monthly for larger merchants.

In addition to multiple integrations and the processing uptime / redundancy there are other benefits to consider exploring. Another example could be in the case of a declined transaction. If your first credit card processor has returned a decline message, you don't have to give up quite yet. You can use Spreedly to re-route and attempt a declined transaction a second time at a different credit card processor. The reason for doing this is admittedly not obvious. You be asking "If one processor declined a transaction why would another approve it"? There are valid reasons why this can happen. It would get too far beyond the intended scope of this discussion to get into a lot of detail, but follow this link to find a detailed discussion on the topic.

In brief, a lot of declines are instigated by the card issuer. The card issuer will see a transaction request come in, and their anti-fraud algorithm evaluates whether the transaction appears legitimate. If it's the middle of the night and the transaction is submitted to a Canadian credit card processor, it's at least potentially feasible that the card issuers anti-fraud algorithm could identify this as outside of the customers purchasing profile. However, if after the decline was received that transaction can be resubmitted to Spreedly to a second processor based in Europe, where it's the middle of the morning, it's at least conceivable that an approval could be issued on the second attempt. It's not an exact science and it's a moving target, but when you get into the world of optimizations and global e-commerce these things make a difference (Especially for larger merchants that are processing a lot of money). For the record, this is exactly the type of credit card processing consulting that we do at Merchant-Accounts.ca. The ultimate takeaway point on declines is that if you have a high-volume business the cost of making a second attempt can be well worth the effort if it results in even a modest boost in approval rates.

There are both advantages and disadvantages to using a 3rd party tokenization services such as Spreedly. It's important to evaluate your unique business case. (If you need help why not contact us to discuss your project). We'll provide a list of the major differences below.

Benefits of in-house (at processor) tokenization

• Some credit card processors will include a tokenization service fore free. If your credit card processor offers credit card tokenization at no additional cost this is an excellent value. We do this at Merchant-Accounts.ca.
• If you use the processors in-house tokenization platform you should receive the lower interchange rates because the transactions should be properly flagged. Make sure you inquire to make sure you are getting this benefit and are coding it correctly. If you need help with this contact us.

Drawbacks of in-house (at processor) tokenization

• Tokenization is not complex to setup, but it has to be stated somewhere that it will be more difficult than just storing the card numbers yourself since you do need to set it up. However, that's more than likely far outweighed in most cases by the increased PCI compliance burden of storing card numbers. If you can reduce the sensitive information on your server it's a good thing. You'll have to evaluate this yourself but most businesses can benefit from tokenization.
• You are relying on your payment processor to provide your data if you ever want to move. You should seek confirmation from your payment processor in writing that your data will be released (albeit in a secure fashion) if a migration to a new payment processor ever must occur. This may seem obvious but you have to remember: they have your data, and you need to make sure you can get it if it's ever needed. This is a good time to remind merchants that there are many good, honest payment processors out there, but unfortunately there are a few bad eggs. You do not want to be beholden to their whims trying to get your data if they aren't playing fair. Research to find a good and reputable processor, and get it in your contract, or at least in writing, that in the event of switching to a different payment processor that they will release your tokenized card data.
• Similarly, although it's unlikely, if a payment processor ever suddenly went out of business you could lose your data. This isn't a drawback of at-processor tokenization, it's a drawback of any type of tokenization. You are outsourcing the storage of your cardholder data and that comes with the inherent risk of not having control of your data. With that having been said, if you are picking a credible and reliable service provider it shouldn't be a major concern, but it is a consideration.
• If you use an in-house tokenization service provided by your credit card processor you won't get some of the additional benefits that a 3rd party tokenization service can provide. For example, the ability to route transaction re-attempts in the case of a decline or during outages.

Benefits of 3rd tokenization services (ie: Spreedly)

• Are more likely to have a clear policy in terms of retention of data and who owns the card data and are more likely to be willing to release it to you than some credit card processors (but you should still seek this confirmation in writing).
• Improved redundancy, can automatically route transactions to backup processors during downtime
• Multiple payment gateway integrations means an easy technical deployment for multi-region payment processing.
• Transaction re-attempts and other business intelligence tasks (to increase authorization rates).
• The tokenization service provider will have many integrations to other payment processors. That means if you ever want to change processors you can do so quickly, and without needing to re-integrate your website. It means very little technical work and a lot of easy portability. This can put you in a desirable position in several ways, for example, when renegotiating your rates with your payment processor - because if they aren't treating you right it will be easy to move to a different processor.

Drawbacks of 3rd party tokenization services

• The reduced interchange costs may not be passed on some transactions (routed transactions) and possibly not on some gateways depending on the integration.
• There is a potential cost issue, especially if you do small tickets and your credit card processor offers a free tokenization service that you could be using.
• When re-routing transactions to other payment processors or backup payment processors there is a potential higher incidence of declined transactions because CVV codes will not passed to the redundant backup processors. CVV codes are the 3 digit codes on the back of each credit card, and are never allowed to be stored. This means that when a transaction is re-routed by the tokenization service the backup processor won't have the CVV code, and slightly raises the possibility for a declined transaction).
• Although it's unlikely, if your tokenization service provider suddenly went out of business you could lose your data. This isn't a drawback of just 3rd party tokenization services, it's a drawback of any type of tokenization. You are giving your data away, and that comes with some risk. With that having been said, if you are picking a credible and reliable service provider it shouldn't be a major concern, but it is a consideration.

Summary

Although tokenization sounds complicated, it's fairly simple to implement. You have a few options to consider as you set it up.

• If your business does recurring billing transactions I strongly encourage you to make sure you are qualifying to receive the lower interchange rates that recurring transactions qualify for.
• If you are using an in-house tokenization service provided by your credit card processor try to choose a payment processor that doesn't charge for the service (like us at Merchant-Accounts.ca!).
• If you are using a 3rd party tokenization service like Spreedly try to take advantage of the many additional benefits, such as the portability of your data, and redundant processing in the event of outages.
• When tokenizing your customers credit card information you are giving up some control over your user data. This means that you should be vetting your provider and doing your research to make certain you are choosing a good reputable service provider.

If you are feeling overwhelmed don't lose sight of the fact that Rome wasn't built in a day. You can always start simple. You don't have to concern yourself with the more advanced aspects explored in this discussion (such as making sure your transactions are qualifying for reduced recurring billing interchange rates). Don't lose sight of the fact that ultimately your goal is to make sure you aren't storing cardholder data. Even if you accomplish only that and don't worry about anything else, you'll still have reduced a lot of the security concerns facing your business. Over time, you can build on that and apply some of the more advanced strategies discussed in this article.

---

Need professional guidance?
Contact us for a free one hour consultation.

---