Tokenization

TranSafe can generate "tokens" that can be used in place of sensitive cardholder data.

The use of data "tokens" as a substitute for sensitive cardholder data has achieved widespread acceptance among merchants seeking to minimize or eliminate cardholder data in their information processing systems. In response to the many different "tokenization" solutions offered by the myriad of competing vendors, the PCI Security Standards Council has issued an Informational Supplement entitled "PCI DSS Tokenization Guidelines" to provide guidance for payment industry stakeholders when developing, evaluating, or implementing data replacement technologies.

Data Replacement Overview

In its most basic form, data replacement technology, or "tokenization" is a process whereby, when card data is first received by the merchant, the card number is stored in a secure database environment, and a link, or "token" referencing that entry in the database is generated and used in place of the actual card data for all subsequent processing operations. For example, merchants who keep card numbers "on file" for use in future transactions traditionally simply retained sensitive card data together in the same database with other information such as customer names and addresses, an approach that places the entire customer database -- and all of the systems that access it -- into "scope" for PCI compliance. With tokenization, however, the actual card data is securely stored in within TranSafe's validated card vault, and only the corresponding "tokens" are stored with the customer data, removing the customer database and related systems from "scope" for PCI compliance since they no longer will contain any sensitive cardholder data.

The method by which a tokenization solution generates tokens, the manner and location in which the actual card data is stored, and the process by which tokens can be used to retrieve or otherwise reproduce the corresponding card data can all impact the security provided by any particular tokenization solution and the steps required to ensure PCI compliance. This page describes the tokenization features of the TranSafe Gateway, and explains how those features align with the PCI Tokenization guidelines, and how they can be used to reduce the scope of work needed for achieving and maintaining compliance with PCI requirements.

Data Replacement Features

Tokenization can take multiple forms within the TranSafe systems. The transaction tracking identifier (TTID), for instance, may be used instead of the card number when performing subsequent operations such as tip adjustments, voids, refunds, and reversals. Application programs typically use TTIDs instead of the actual card numbers for performing those operations. TTID tokens can be used as short-term tokens as they remain valid until the transaction batch data has been purged, or "secured," which by default is 120 days.

The DSS (Data Security Shield) subsystem provides recurring billing and secure, permanent, "card-on-file" features. The DSS functionality generates unique, random, token values (not based on the original card data) that can be stored and used in place of actual card numbers. The tokens provided by the DSS subsystem remain valid until the underlying credit card expires, this may be up to 24 months or more.

Finally, the CardShield® ticket functionality can be used to store sensitive data prior to authorization that is only valid for a few minutes. This functionality is used for split knowledge purposes to avoid sending sensitive data through a system trying to reduce their PCI scope, but where this system may need to reference (but not retrieve) the sensitive data to complete an authorization. This feature is often accessed through our POST protocol.

Conclusion

When tokens are used to replace PAN in the merchant environment, both the tokens and the systems they reside on must be evaluated to determine whether they require protection and should be in scope for PCI DSS. To be considered out of scope for PCI DSS, both the tokens and the systems they reside on would need to have no value to an attacker attempting to retrieve PAN, nor should they in any way be able to influence the security of cardholder data or the CDE. TranSafe's proven tokenization features enable achieving those objectives easily, with little or no disruption to existing systems.