Oops! My Customer Just Made Me Non-Compliant With PCI

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

Merchants everywhere love to connect with their customers by E-mail, Twitter and SMS. Such regular and personal communication helps build a strong relationship and loyalty. The problem is that customers sometimes take this communication a bit too far. They can E-mail, tweet or text their payment-card information to a merchant without being asked. When this happens, the merchant is left with a very painful, but very straightforward question: What do I do with that transaction?

If a merchant rejects the transaction, the customer may be offended, confused or just go away. These are bad outcomes for the business, whether it is a retailer or a charity. On the other hand, processing the transaction means the particular communication system (and everything connected to it) is now transmitting cardholder data. This is the case even if the customer wasn't asked to provide the information. Processing the transaction can increase the merchant's PCI scope, thereby leading to an even worse outcome with broad implications for the enterprise.

To solve this problem, we need to understand PCI scoping, the merchant's own policies and its procedures when unwanted data comes streaming over an open public network.

Every merchant knows one of the most important steps in managing PCI compliance (and maintaining sanity) is to limit scope. That is, minimize the number of systems that store, process or transmit cardholder data (a.k.a., the cardholder data environment), along with any systems that connect to them. The next step is to isolate these systems and processes from the rest of the environment.

This is a great plan that can—but does not have to be—easily defeated by customers' unsolicited E-mailing or texting of their payment-card information (i.e., the primary account number [PAN]). Everything depends on what the merchant does right after that unsolicited data comes into its network.

The first step is to look at the merchant's policies. Does it state explicitly what are the approved payment channels? I like to see a statement like: "Mega Corp. accepts card present, mail order, telephone order and Web transactions at company locations." That is, does the merchant exclude channels like E-mail and/or even fax?

The next step is to check the actual practices. Here is the painful, but unavoidable part: The merchant cannot process the errant transaction. If it does, then regardless of the policy, that merchant is actually accepting and processing E-mail, text or Twitter transactions. That means those systems are in the merchant's PCI scope.

I see this situation all the time.I see this situation all the time.My advice is that merchants should have a process in place to deal with this possibility. First, destroy the offending message. This is critical. By itself, a customer sending his payment-card information does not drag a merchant's E-mail system into PCI scope if it is not that merchant's policy or practice to process the transaction. Because E-mail systems remember everything, the idea is for the recipient to delete the message from its inbox and everywhere else it can immediately.

The next step is to contact the customer. By this, I do not mean hit "reply," which sends the offending card data back through the merchant's system a second time. The purpose is to tell the customer that transaction cannot be accepted. This is a good time to have a prepared statement worked out in advance that can be sent. That statement should explain the merchant's policy, why sending card data over open networks is a really bad idea, that the business wants to protect its customers from identity theft and any other messages the merchant wants to convey. Then tell the customer how he can go online, call on the phone or mail his card information to the merchants securely. Treat the situation as an opportunity to communicate with customers.

Above all, the merchant must not process the transaction. Do not even think about it. This is where security training and staff awareness come into action.

If merchants take these steps, this QSA would say their E-mail or similar system is not in scope. If, however, the merchant describes the risks to the offending customer but processes the transaction anyway ("just this one time"), its actions do not match its policy and it is processing transactions by E-mail, SMS, Twitter or whatever. Therefore, those systems are clearly in scope for PCI.

We have patches for security flaws. It is a shame, but we can't yet patch the human element (I've seen a tee-shirt with a particularly unsympathetic statement on this issue). Until that day, merchants need to enforce their policies and make sure their staff training covers a situation where a customer wants to help out a little too much. Handled properly, it can be a positive experience and a good lesson for the customer. Handled poorly, it can lead to an unacceptable expansion of the merchant's PCI scope, which means it may be the most expensive sale ever made.

What do you do when a customer E-mails or texts their card number to your helpdesk or call center? I'd like to hear about your procedures. Either leave a comment or E-mail me at [email protected].