© 2011 Mercator Advisory Group, Inc.
S O L AT E
E M OV E
RO T E C T
OKENIZATION AND THE
TNSPay is one of the world’s most widely used managed ePayment services. It is focused on the needs of card-not-present merchants (eCommerce, MOTO, IVR, Mobile Internet) and provides them with a simple way to authorize and settle card transactions, combat fraud, enhance card data security, and simplify their PCI DSS compliance efforts. The TNSPay gateway processes more than a quarter of a billion transactions a year for over 30,000 merchants, helping grow their business.
What if card holder data could be removed from your eCommerce environment? It can with TNSPay. The challenges of storing, transporting or processing credit card information can be greatly simplified, and the investment needed to meet Payment Card Industry (PCI) compliance standards reduced, through the secure, flexible
and empowering capabilities of TNSPay.
Secure – you can completely remove card holder data from your environment. The TNSPay platform is PCI DSS certified and enables your card holder data to be easily captured within your existing payment workflow, isolated so it never touches your payment environment and tokenized for your future use. This approach helps merchants reduce the scope of their PCI compliance, saving them expense and effort.
Flexible – one connection to TNSPay puts the power in your hands. Transaction Network Services (TNS) is a neutral partner, with diverse connectivity that gives you access to payment processors around the globe. TNSPay provides you the flexibility to send your tokenized payment transactions to one or more processors, regardless of who your processor is now or in the future. TNSPay provides connectivity to processors in the US and over 25 other countries.
Empowering – control your own branding and customer experience in order to grow sales. Unlike most hosted payment solutions that restrict a merchant’s ability to control branding and customer experience during the checkout process, TNSPay Hosted Payment Forms has no impact on the appearance of your website or your ability to manage your customer interaction. At checkout, your customer never leaves your website pages, so you have complete control. You define the information fields on your page that you want TNSPay to directly capture and TNSPay handles the transaction authorization from there, so the card data is never entered into your environment when the order is submitted. If you choose, you can have TNSPay retain the card information in a PCI-DSS secured facility and return a token back to you for needs such as marketing or customer support, further helping to eliminate card data from your environment to reduce the scope of your PCI audits. And since the Hosted Payment Form solution gives you the flexibility to post data to the TNSPay server at multiple points during the checkout process, customer data is not lost when a customer navigates back and forth within a session. This also gives you the ability to validate certain customer data points prior to the end of the checkout session, helping to increase the likelihood that the sale will be authorized when the customer submits the order. All of this can help increase
Table of Contents
You Can’t Completely Outsource PCI ...4
Tokenization: Not Just for Card Numbers ...4
The PCI Challenge ...5
Tokenization in e-Commerce ...5
Deploying Tokenization ...6
The Upsides of Tokenization ...6
Tokenization Considerations ...7
You Can’t Completely Outsource PCI
Fully outsourcing PCI compliance is impossible. Every merchant is responsible for meeting PCI compliance and cannot turn over that responsibility to another entity. Every other participant in the payments chain - FIs, processors, gateway operators - is similarly responsible for their own PCI compliance. But the burden falls most broadly on the U.S. merchant cadre of over six million.
Outsourcing portions of PCI compliance, on the other hand, is eminently doable. Tokenization and encryption are two technologies that enable a merchant to mitigate the risk of breach, and both approaches represent opportunities for third party providers to assume critical functions that reduce the merchant's need to store, transmit or process card numbers and associated customer data.
This report addresses two issues. First, it briefly looks at merchant strategies to meet and lower their PCI
compliance burden. Second, it examines tokenization in greater detail. Tokenization is an option gaining currency among merchants seeking to mitigate their PCI compliance costs. While there are issues with tokenization, its appeal is strong. Given the comparative simplicity of deploying tokenization vs. encryption, there are a number of vendors stepping up to provide tokenization to e-commerce, brick-and-mortar retailers as well as enterprises handling the wide range of personal data.
End to End Encryption is Another Path
An equally important approach under consideration by brick-and-mortar merchants is end-to-end encryption of card numbers. Multiple competing vendor camps have emerged to encrypt card numbers at the POS terminal and to pass those numbers, fully encrypted within the current encrypted communications links, through to either the merchant’s central data center or to a third party gateway or processing provider. VeriFone and their partner RSA lead one approach. Magtek and its service subsidiary Magensa have partnered with POS terminal makers
Hypercom and Ingenico to deliver a second approach. Heartland Payment Systems has deployed end-to-end encryption based on Voltage Security technology.
Tokenization: Not Just for Card Numbers
Tokenization replaces a PAN with another number. The merchant uses this new number to process and track the transaction on its own systems. This new number is called a token, a proxy, representing the customer's card number.
Tokenization is a technique appropriate to handling any critical information. Social security numbers, a datum with high risk for identify theft, is a prime candidate for tokenization, used extensively in education, government, healthcare and insurance. Some of the tokenization vendors are taking their tools to these markets as compliance with Gramm-Leach-Bliley's privacy provisions is a major driver.
Eliminating personal information through tokenization or any other technique from the complex systems of insurers, universities, government and other institutions is no trivial task. Systems routinely use these numbers as
key data elements for integration of disparate systems. These numbers are used as key fields for queries and reports. Changing these operationally critical functions is time consuming. But given the customer trust relationship these entities must maintain, the effort looks increasingly worthwhile.
The PCI Challenge
Merchants are confronted with two risks. The first is failure to meet PCI requirements represents an immediate downside outcome. PCI compliance is a requirement of accepting payment card transactions. If a merchant gets out of compliance the acquiring channel can raise the cost of processing, levy pass-through fines and stop
processing consumer payments altogether. For merchants, that’s a very bad thing. The second of course is a data breach, a damaging outcome with significant costs for merchants in terms of brand reputation and remediation.
Keeping Up with PCI Requirements
But a major challenge for merchants with PCI is the changing nature of PCI requirements. PCI’s scope continues to expand each year, evolving in response to successful new intrusion techniques. This evolution (or “scope creep” for the fatigued merchant infosec team) creates a concomitant increase in the compliance burden. New security hardware, software and procedural requirements add new costs such as last year’s addition of a hardware-based web application firewall for web merchants. Even with a 12 – 18 month grace period, it is still real cost.
“Compensating controls”—essentially approved workarounds—are possible but they must be reviewed once a year and can be revoked at any time if forensic analysis and experience demonstrate that the control is no longer adequate. So, any strategy that reduces PCI scope is a welcome alternative to this increasingly costly status quo.
Tokenization in e-Commerce
e-Commerce is a first rate application of tokenization. Online the process is quite straightforward and should be familiar to those responsible for shopping cart functionality. Once the customer has completed shopping and chooses to pay with a card, the control of the transaction shifts from the merchant to the tokenization provider. The customer enters the card data into a webpage or data field managed by the tokenization provider. Once the customer presses Submit, the tokenization provider sends the authorization request upstream as usual and returns a token to the merchant representing the transaction. Payment data is never stored on the merchant’s servers. Today, shopping cart software captures the card number. While the shopping cart application may mask the full PAN when displaying the card number on the consumer’s web page, the full PAN is in fact held by the shopping cart platform managed by the merchant. In this mode, the merchant is responsible for the care and control of the card numbers it collects on its servers.
A superior approach is the use of hosted payment fields. Using this approach, the data entry fields displayed on the merchant’s payment page are delivered by a third party payment services provider. The card number data entered by the user never touches the merchant’s systems and is thus out of PCI scope. The payment services
provider returns a token, and not the source card number, to the merchant. Clearly, hosted payment fields and tokenization produce a better approach. They reduce the risk of card number compromise.
Unlike hosted payments pages, hosted payment fields let the merchant easily manage the look and feel of the payments page. And, instead of injecting the additional step of the Verified by Visa experience or a new method of payment, the application of tokenization in e-ecommerce makes sure the card number never touches the
merchant's servers. If there is a data breach, it is not, at last, the merchant’s fault.
Typically, the token format obscures the first 12 digits of the card number and leaves in the clear the last 4 digits of the 16 digit card number. At least for the last four digits, this approach mimics standard truncation used for receipting. This approach is designed to minimize the impact on the merchant's internal reporting and database systems that rely on predictably formatted card data. Tokenization engines may be tuned to minimize the impact on existing merchant systems or optimize security.
While tokenization vendors obviously tout the simplicity of replacing PAN data with tokens, the extent to which the token mimics the card number format that drives the merchant's reporting systems has everything to do with the pain of adopting tokenization. For some merchants, the task is relatively painless. Once hosted payment fields are in use, the merchant sees no new card numbers, only tokens and no time consuming page redirections to hosted payments pages are required. But PCI requires that all systems that touch card data be compliant – and enterprises with 20 such systems touching cardholder data are not unheard of. It may take six months and more to complete the task across the enterprise.
The Upsides of Tokenization
PCI Scope Reduction: Obscure the Numbers or Firewall the Network
In terms of PCI scope reduction there are two principle avenues to take: card number obfuscation, like tokenization and encryption, and network segmentation. If a merchant’s computer communication network requires a forklift upgrade of expensive routing gear, then the merchant may opt to follow the card number obfuscation route. Eliminating flat spots in the network with new routers and switches capable of VLAN segmentation that replace dumb Ethernet hubs is expensive. The hardware is costly and its configuration takes time to see through testing.
Shifting the Liability and Risk
Tokenization providers are willing to assume some level of liability that results from a data breach of the data stored on their systems on behalf of their merchant customers. That is, of course, one of the major attractions of the service offering. The upstream supplier would be at fault if its systems were breached and not the merchant itself. What’s not to like in that scenario?
Tokenization when Sharing Keys is Impossible
A potential application for tokenization is when multiple firms touch a single payment transaction. Property management companies who interact with outsourced contact center personnel must be able to share payment information when sending it to their hotel chain or rental property owners. There may be multiple security holes in this link if one or more are not PCI compliant. Even when numbers are encrypted in transit, they must be decrypted at each location because key management or shared keys are not available, further exposing the transaction to compromise. If tokenization is employed and each merchant uses the same tokenization provider, security improvements could result and business processes streamlined. Certainly, adding key management to a multi-merchant, multi-participant business process adds unwelcome and expensive process complexity.
Some considerations are downsides. Others are specific to the enterprise’s need. Others just have to be factored into the enterprise’s approach to PCI compliance and vendor decision making.
It's MY Data
Line of business managers and the application software they depend upon is reliant on card numbers for data access and reporting. The cost of changing over to a token format may not be justifiable after encryption is in place. Security managers, further down the political food chain, are hampered in their ability to push for
tokenization. While tokenization reduces risk, the cost / benefit ratio of tokenization versus changing thousands of lines of business software is a challenging case to make. But, as the data breach problem continues to expand, that argument has become easier to make.
It is highly unlikely the merchant's need for access to true card numbers can be entirely eliminated. For example, the Sales Audit department may need access to the tokenization server on a regular basis. With each access by these users logged and those logs reviewed regularly, risk may be mitigated. Because humans are not especially good at the routine, the more automation that is applied to routine reviews of log files, the better.
Not Another Third Party
Tokenization is a simple idea with complex execution. Merchants are attracted to that proposition but are looking for it to come from their most reliable partners. From a partner that won’t lock them in to a larger relationship with limited flexibility because they have control of your critical payment or other customer data. Most
tokenization providers are smaller firms and for larger merchants that in itself may increase perceived risk. What happens if the tokenization provider fails? Besides the merchant itself, acquirers and processors want to know that their merchants won't be left hanging should a provider fail. Therefore, business stability is critical for a tokenization provider because the enterprise’s entire payments software system is now tied to an external party’s platform that may disappear. As a third party service, standard software protections like escrow of source code are of no use. Given the comparative youth of some of these providers, careful vetting of their financial condition
is just one step in the due diligence process. Looking at the vendor’s other revenue sources may also reveal clues to its sustainability. Until de facto standardization emerges caveat emptor must guide decision making.
Token database portability is also an issue. If the merchant becomes dissatisfied with the tokenization provider after a year, for example, the merchant should be able to securely move its token database to a new provider. If the tokenization service is locked, by contract, into a larger relationship, this ability to move the token database becomes even more important.
The Fat New Target or Centralizing the Risk
Willie Sutton might have liked tokenization providers. They are, after all, where the money is in the form of the true PANs. Along with every processor, each one of these vendors is setting itself up as a target. The fact that they all must be PCI compliant is table stakes to be in this game; it says little about their security architecture.
Processor breaches like Heartland provide sad evidence of that point.
Vendors of tokenization solutions should expect hard questions from merchants, upstream processors and financial institutions on how they store and access PAN-related data. There should be a robust set of encryption steps and other techniques within the tokenization vendor’s data center that make assembly of coherent payment data without owning the keys and the database impossible.
Each merchant has to decide if this level of protection is adequate. While it reduces the PCI burden, how much does it reduce the risk of the business impacts associated with a data breach? Finally, these vendors may be a single point of failure unless redundant operation is assured. If the tokenization provider goes offline, what is the impact on payment acceptance?
So Many Token Types to Choose From
A significant concern for acquirers and merchants alike is the multiplicity of tokenization approaches. Between multiple vendors and internally developed approaches, there is no standard approach to tokenization. Many use a 12/4 format, obfuscating the first 12 digits of the PAN and leave the last 4 digits in the clear, essentially taking a page out of the card number truncation book. Others use different schemes entirely. How a token is created varies. What is most important is whether your provider can support the tokenization format that best fits your needs.
More than Token Account Control?
As these third parties add value, they also gain some level of account control. A merchant cannot easily switch from one tokenization provider to another unless there is 100% functional equivalency (what are the odds of that?). If a vendor ceases operation, gets acquired and stops employing a particular tokenization technique, it puts the merchant's card processing operations at some risk. For that reason, acquirers are also concerned. They do not want anything to interrupt their merchant’s transaction flow. Portability, or at least guaranteed access to the token database, is desirable.
The Strong Buffer in the Gateway
Tokenization may be delivered via a third party gateway provider. In this case, not only does the merchant make use of its token management services, it may also use the gateway as a buffer between the merchant and the acquiring bank. Of course, if the gateway operator hooks into multiple payment processors, it may also act as an interconnection point, giving merchants flexibility over which payment processor to use for different payment types. TNS, with its TNSPay ePayment gateway, occupies this space.
Isolate, Remove, Protect
PCI and enterprise-wide information security are two different animals. PCI recommendations are the result of a thorough examination to produce a stronger payments ecosystem, both within a single organization and across multiple organizational lines. But because the payments infrastructure was not built with today’s e-commerce security risks in mind, PCI is, to be harsh, about making the best of a bad job.
The truth is that tokenization’s short term benefits accrue to the merchant and its PCI compliance burden. The reduction in scope of the audit and the security monitoring posture taken by the merchant are welcome improvements and the results are worthwhile. Isolating the systems that handle card data within highly secure walls and removing card data from merchant systems protects the entire process with the merchant as the principle beneficiary.
These benefits are especially relevant to the e-commerce merchant and e-commerce channel operator. Hosted payment fields maintain a seamless payment experience for the online consumer and give the online merchant a way to avoid card number handling entirely. By coupling those advantages with a flexible gateway partner relationship the commerce merchant’s fraud management team is able to build a secure, PCI compliant e-commerce payments system that supports the business needs of the marketing function.
External publication terms for Mercator Advisory Group information and data: Any Mercator Advisory Group information that is to be used in advertising, press releases, or promotional materials requires prior written approval from the appropriate Mercator Advisory Group research director. A draft of the proposed document should accompany any such request. Mercator Advisory Group reserves the right to deny approval of external usage for any reason.