Can I show Credit Card Data to final customers and be PCI Compliant?

Question

I work with reservation management syatems. In the hospitality industry there is the concept of credit card as guarantee. By it when making any kind of reservation you are asked for your credit card info in order to secure the reservation, however you may only be charged, depending on the booking conditions, in the case of a no-show or other concepts that may only occur after the booking process.

For example I may book in January a safari tour happening in October.

So basically for as long as the reservation is valid, you must hold onto the credit card data.

Once day of the booking occurs and there is a no show for example. The hotel personnel (my customers) can query the user's credit card data and charge it.

So if I were to store credit card data in a PCI compliant way, can I then show the credit card data from user's to authorized hotel personnel (customers) that must use it to charge the user?

Once again I clarify, My customers are Hotel Personnel, Tour Operators, Travel Agencies. And the Users of the systems are the people booking through it and giving their credit card numbers.

Answer 1

Ultimately, I think you're going to have to figure this out with your PCI auditor, which I am not. I think you're going to have a hard time figuring out how to do this is a way that is a) not overly burdensome to you and the ultimate users of the card data, and b) leaves you with a system that is still PCI compliant and that your auditor will give a stamp of approval, but I also don't think PCI DSS v3 makes it impossible.

This is the most significant issue:

Once card data enters a PCI compliant system, it cannot be extracted and delivered via non-compliant means. This means that you can't get the card data out, and email it to a hotel, for instance, or give to someone over the phone. It must at all times be encrypted, access logged, and unprotected PANs only displayed to those with a legitimate business need.

Now, given that the hotel personnel do in fact have a legitimate business need (they need to be able to charge the card) if access is appropriately restricted and audit logged, you may be able to successfully argue this. It still elevates the level of risk, however, and any given auditor may refuse to buy this line of reasoning.

You would be far better off if you could send the data directly to the hotel or tour operators own PCI-compliant processing systems and let them worry about it from there, instead of having to work through human intermediaries.

Answer 2

You should never display full readable credit card to anyone (includes authorized users). It is a bad security practice. If you do, then you'll need to implement even stronger access and monitoring controls in place to make sure the credentials for the authorized users are not compromised and hackers are not stealing away CC data. Better off simply displaying last 4 digits of the CC.

Answer 3

Credit card data is not homogeneous. There is some information you can show and others you aren't even allow to store. For instance, you aren't allowed to store the CVV2 code. Yet other credit card data is the cardholder name, the transaction history, etc. So you have to look at it on a field-by-field basis.

Generally speaking, best practice is minimization - never make more data accessible than what a particular person needs to do the job. For instance, customer service reps in a call center shouldn't be able to see CC numbers at all.

Answer 4

You can show the full credit card data as long as user passes the MFA(Multi factor authentication). Also phone number which is used to validate the MFA, should be attached to that user. No links should be available to redisplay the card data again. Also page should never be cashed.

Answer 5

Your payment gateway probably has a way of storing and tokenizing credit card information on their servers in a PCI-compliant way. For example, if you use Authorize.Net, you can use their Customer Information Manager service to store and tokenize the end-users' card info securely on Authorize.Net's servers.

Using such a service, when the end user books a reservation, you can store their credit card info on the payment gateway's servers. When you do so, you receive a token back, which you can store in your database. Whenever you need to run a transaction to that customer's credit card, you can do so by providing the token.

This way, you do not have to store the end users' credit card information on your servers, and you are PCI compliant, and you can run transactions to the end user's cards at any time (using the tokens).