What is Credit Card Tokenization?
What is the biggest problem with Credit Card Data?
A tongue in cheek reply would be: "The Credit Card Data dummy!" While it is a tongue in check reply, there is some truth to it.
Having been involved with many implementations, I have seen this over and over. It is always an issue securing and protecting this data and only displaying it to those that need to know. Here are some classic issues I have seen.
Most SAP infrastructures include a Quality Assurance client for testing changes before moving these to the Production environment. And it is very often a copy of Production at some point in time. And what comes over with that copy? All the customers Payment Card data. So you need to do 1 of 2 things:
- Purge the Credit Card Data (have to write a custom program)
- Encrypt that data - very often not activated in the QA environment. And quite a process to turn on.
The Result of Encryption
When a credit card is encrypted in the database, it is displayed as ************4141 for example.
The problem is that it needs to be displayed everywhere like that. I have seen instances where someone will run a report and the unencrypted credit card will show up. Or someone enters a transaction from a different direction, or accesses a rarely used screen, and suddenly the unblemished, unencrypted credit card data show up.
And in reality, the Payment Card is still saved in our database. And we are responsible for securing and protecting that data.
What is a Token
What if we could move the Credit Card data from our database and give it to another server (called a Token Server)? The Token server then gives us back a Token that is representative of the Credit Card data. So the actual Credit Card data in our databases, is now replaced by a Token data.
For example: It gives us back ************4141 to store in out database. The only link from the token to the Credit Card data is now held on the Token Server.
Advantages of Tokenization
- Now we do not have the credit card data in our database. If someone hacked into our database or a user accessed the customer Payment Card data, they could not do anything with the ************4141.
- Obviously the Token Server needs to be secured and PCI compliant. But this means that we only have one system to secure, instead of potentially many systems.
- And if we contract with a 3rd party to supply this Token Server, we have now moved the responsibility off site to another company whose core business is to secure such data and remain PCI compliant.
- This reducing our costs.
- If the Credit Card data is ever needed, a query goes out to the Token Server which returns the Credit Card Data. This makes PCI compliance much easier as we do not store Credit Card data on site anymore.
Who offers these Tokenization Services for SAP
Probably the best known of the Service Providers is Paymetric, with their XiSecure Service (they use a 25 Character Token).They have 2 versions of it:
- XiSecure - Onsite local Installation
- XiSecure - SAAS Hosted Offsite Service.
Whilst I have not implemented a Token system yet, it makes sense and would be a useful compliment to a Credit Card Payment System.Hope this brief article helps you understand what tokenization is and how it helps your business.
Feel free to add Comments and Questions.