Merchant Tokenization Strategy

Written by: Srinath Sitaraman

February 16, 2017 - Discussing the relative merits and risks of different merchant strategies used to implement tokenization.

Well before Tokenization became a clichéd word in the post Apple Pay world of payments, many merchants and their acquirers were using tokenization to protect the PAN and other cardholder data for later usage – e.g. for refunds, chargebacks, loyalty/coupons, recurring payments (i.e. gym memberships), reservation look up (i.e. T&E), one-click checkout etc… When properly implemented, tokenization protects data-at-rest and helps to reduce PCI scope, complementing P2PE and EMV to protect card holder data-in-motion and reduce counterfeit fraud respectively. A spate of large scale data breaches in late 2013 and 2014 galvanized several merchants to implement tokenization. The zeitgeist of the time prioritized TSP implementations with the "least time to market". In the past few years however, the increasing need to deliver omni-channel experiences strategies as well as to gain an advantage from the fragmentation within the market have caused merchants to re-examine old strategies and determine if a course correction is needed.

For merchants, there are several approaches to implement tokenization:

  • Build – completely develop an in-house tokenization solution
  • Buy – an off-the-shelf tokenization platform and integrate into the merchant’s existing payment systems/channels
  • Managed tokenization service provided by the merchant’s payments processor or payment gateway
  • Managed tokenization service by a 3rd party TSP.

Depending on the type of tokenization model, the scope of PCI compliance can decrease or increase: The key value proposition of a managed tokenization service provider is to absorb the risk from the merchant by storing card holder data within its environment, thus also limiting the merchant’s PCI compliance scope. However, the managed TSP model, in some cases creates limitations for merchants over the long run, including but not limited to the following:

  • Cost and/or Fee structure and/or Total cost of ownership of a managed TSP
  • Flexibility to connect to other processors for cost, technical or other reasons
  • Convergence of merchant’s wide array of payment channels and systems that rely on the same set of tokens
  • The managed TSP creates unnecessary complexity either for the merchant’s business work flows or ends up creating a complicated user experience for the merchant’s customers resulting in cart abandonment
  • In many cases, the inability to tokenize beyond branded credit/debit cards
  • As the token database becomes larger and more valuable over a period of time, questions over portability of token and customer info (i.e. who owns the tokens and can the Token-PAN mapping be exported if the merchant wants to walk away from the relationship with the TSP)\
  • A lack of influence on Managed TSP's product roadmap which may risk factors of performance, quality, compliance, or the ability to utilize tokens to bespoke use cases in order to build a competitive advantage
  • Inadequate reporting, poor customer service from 3rd party TSP, inadequate insurance that does not meet merchant’s standards etc…

Using a payment processors’ TSP services does tend to create stickiness to that particular payment processor, which is a fact that many merchants have to live with. That said, there are a few payment processors that have decoupled their token services from their core payment processing services in order to allow the merchant to integrate into other payment processors while still using their token services. It's important to note that the potential technical freedom a merchant can achieve still rests upon the favorability of the business coupling to the original processor. Nonetheless, if the merchant is working with processors that offer a decoupled managed TSP solution, it might be worth exploring.

On the other end of the spectrum, building one’s own tokenization system and integrating into the merchant’s existing payment system is a significant undertaking, especially after relying on a 3rd party to manage the tokens for all these years. Some of the considerations/challenges with the build option include:

  • Impact of diverting resources (time, money, human resources, etc.) to build, deploy and support an in-house TSP from existing core business and otherwise serving customers
  • The extent of the software overhaul needed, while phasing in a new tokenization solution. Additionally, if an existing Tokenization system is being replaced, the odds are that the P2PE communication (if used) is also impacted
  • Minimizing potential disruptions to BAU operations and ensuring a smooth migration path from current TSP to the new TSP solution
  • Possible requirement to re-certify for EMV due to the introduction of the new tokenization/P2PE flow
  • Over the long run, ensuring adequate resourcing to maintain and monitor the in-house tokenization platform and to ensure annual PCI compliance, maintaining adequate insurance to protect in case of a data breach etc… that need to be taken into TCO calculations

Whether a merchant plans to move from an outsource-to-build strategy or from build to a buy strategy, the change in course involves a substantial effort and requires careful consideration of short/long term pains and gains of each option, before making the appropriate choice.


These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.