Can Sensitive Cardholder Data Be Shared Without Worrying About PCI Compliance?

In a previous blog post, Can Cardholder Data be Stored Without Involving PCI Scope?, we discussed how the Payment Card Industry Data Security Standard (PCI DSS) says it is possible to store a unique token that represents a cardholder’s Primary Account Number (PAN).

But can that token be freely shared – and should it be?  The short answer is yes, but read on to understand exactly why.

What does a token represent?

A payment token is only useful to the merchant who owns it, since the process of tokenization renders a PAN useless.  Additionally, the merchant does not have direct access to convert the token back to a PAN – to the merchant, it simply represents a single transaction, specific customer or one of their customer’s payment choices. To a hacker, it is useless, although they may think they have something; if the stolen tokens are format preserving, they look like credit card numbers.

A token is only a representation or a reference to a PAN for the specific merchant for whom it was generated, and the actual PAN is stored outside the merchant’s data environment: inside a third-party token vault.

Safer than a double locked box

To make a token work for a payment, the merchant sends the token to their token service provider (TSP) or payment processor (depending upon capabilities and token type) as part of the payment process and the TSP looks up the PAN in the secure token vault from within their safe harbor. The TSP then encrypts the PAN and sends it to the appropriate place for payment processing. When the payment is approved, the process reverses, so the merchant receives the approval with the initial token. The token can only work as a payments instrument within this secure process, so no amount of processing power could ever reveal the PAN.  That is why PCI DSS says merchants and payment service providers (PSPs) can store payment tokens in their environment.

Mission: Impossible?

Let’s say Mission: Impossible is real, and a super hacker obtained all of a merchant’s tokens. The super hacker would realize they do not have actual PANs when they do a Luhn check.  To try and utilize the tokens to make money, they would have to create false transactions through the merchant’s token service provider to get the money. But the money would go into the original merchant’s account by default, so they would most likely have to break into your acquirer and/or token service provider and then figure out how to reroute the payments through a series of untraceable accounts. All this without anyone noticing? That’s why it only happens in the movies.

So, you’re saying it’s safe?

Understanding that a token is irreversible, and only can be used within a specific process that never exposes the PAN, you should feel safe sharing it. Even PCI DSS, which is responsible for dictating payments security, says it is how you should securely store PANs for reuse. Finally, since it is not sensitive cardholder data and cannot be reversed back into a PAN, it is safe to share.

In fact, while the original payments system is still within PCI scope (tokenization just significantly reduces scope, as outlined in the PCI DSS Tokenization Guidelines), as long as only the token and no other sensitive cardholder data is shared, then no system has been exposed to PCI scope. Thus, you can feel safe about sharing this token with multiple systems inside, and outside, your organization. 

There are a number of benefits to sharing token with other systems… but that’s a topic for another post. 

For a full resource set of tokenization resources, read the blog: A Primer on Tokens, Tokenization, Payment Tokens and Merchant Tokens or the eBook An Executive’s Guide to Payment Tokens.