Migrating Tokenized Data…Once Should Be Enough

Tokenization services have been promoted heavily and widely implemented by merchants across all segments for in-store and eCommerce channels. In most cases, you work with your payment gateway or processor for tokenized data services. The provider is securing credit and debit card data in their systems and replacing it with an algorithmically derived token which cannot be hacked or reverse engineered by fraudsters. Additionally, you may be storing, tokenizing or vaulting other customer confidential or personally identifiable information (PII).  

If you’ve implemented tokenization or vaulting as a core foundation of your data security program, you’ve taken important steps to protect your customers and your business from data breach, fraud, business disruption and the risk of reputational damage. 

CHANGE IS AROUND THE CORNER

Just when you are feeling good about your security posture, what if the Chief Technology Officer (CTO) announces a decision to move your payments business to a new provider? And, better yet, it’s your job to work with the soon-to-be former service provider to securely move your payment data to the new provider.

Would you know where to start?  

You might begin by logging a support ticket with your current payment provider with a subject along the following line— ‘Migrate tokenized data to new provider’.  

In some cases, there may be language in the agreement which permits the provider to retain or securely delete your data rather than return it to you or the new provider. These prohibitive terms have become less common recently but, depending on the provider and the age of your agreement, this could be a sticking point.

Once you’ve successfully navigated the ‘retention’ conversations, you will likely be referred back to Support to assist with the data migration process.

IT’S WHAT AND (SOMETIMES) WHO YOU KNOW

Providers have a wide range of processes for handling data migration requests. Frankly, they run the gamut from well-documented and efficient to slow, cumbersome, and unreliable.  Whatever their process, the provider will require more information to assess your request.

This is where you may need your payments glossary. The legacy provider will likely require:

• Proof that the new provider is a PCI Level-1 Service Provider. Your best options for this will be:
  • A current Attestation of Compliance (AOC) for the new provider conducted by a QSA (Qualified Security Assessor) or
  • An up-to-date listing in Visa’s Global Registry of Service Providers under Validation Type ‘PCI DSS’.
• Delivery of the new provider’s PGP public encryption key, which typically must be 4096 bits or greater in length and hosted over HTTPS on one of the processor’s domain names referenced in their AOC.

If your provider is in the well-documented and efficient group, these two requirements should be the crux of what’s needed to complete payment data migration. Unfortunately, all too often, coordination between your company and the two providers (old and new) can be painfully slow and difficult to coordinate.

If you run into issues, you may consider asking for someone in the provider’s Data Security or Compliance team to assist. This group is typically highly responsive to any question or issue related to customer data migration.  

A BETTER SOLUTION

One final recommendation… before you sign on for the new provider’s proprietary tokenization service, ask if they support Network Tokenization. Network tokenization is a new standard supported by Visa, Mastercard, American Express and Discover. Once you have a Network Token, it is universal across your sales channels and portable to any other provider without repeating this (sometimes) burdensome migration/conversion process. This is just one of the powerful advantages of Network Tokenization.

For more details, check out our blog post What is Network Tokenization and Why is it the Future of Secure Digital Commerce?