PCI Audit: Using "test" cards

Question

I know that the PCI standard does not allow you to use real credit card numbers on test systems. Visa, Mastercard and Amex supply a list of "test" cards to use. Makes perfect sense, and we have been doing that.

Now, once everything is setup in production, we often need to test the system before allow clients to use it. We have a pre-paid Visa card that we do for the final testing. So this is on our production system, with our payment gateway pointing to the production payment processor. It is 100% the setting that customers will use. We want to check descriptors (what shows up on the statement) and just check that everything will work.

Our PCI guy says that this is totally forbidden. Live credit cards can not be used for testing. Is this true? If so, how you do you do your final testing? Of course any "test" card will fail, as they are not valid cards. We need the card to work, to check the full user experience.

Answer 1

Ask him how you can ensure your system is working, if you can't run a test with a real card, owned by you. Also, what's to say you are testing? Maybe you are placing your own order for your usage. ;)

The rule is designed to prevent you from grabbing all your customers' credit card numbers, and trying to use those in your development environment.

Answer 2

One way to do this sort of testing is to write a payment processor emulator. Write a small program that implements the same protocol as your payment processor. You may have to read between the lines of the payment processor's documentation to do this, but it can be done.

Then, you can use 16-digits strings in credit card number format (Luhn checksum) that don't match any real BIN or IIN. You can do test cases like really long response time, improperly formatted responses, short responses, and a "credit card number" that has a credit limit. You can also have "credit card numbers" that produce specific declines.

Have the emulator always decline on a payment authorization request that has a well-formatted credit card number. Only authorize on a few, specific "credit card numbers" that can't exist in reall life because the BIN or IIN doesn't match a real bank's. That way, when someone's project goes live and they leave it pointed to your emulator or test system, the emulator won't issue fake auths which would cause your accounting system to have problems with a real payment not coming in at settlement.

Answer 3

I was thinking was covered by PCI DSS, but I cannot find in explicitly covered section 3 of PCI DSS 3.1. Did I miss this or this more of a processor/gateway requirement. In either case, it is still a good idea against test accounts.

We have customers that have the same need. One option is to store up some real transaction if using save cards and then run them through as the first transactions. This is more problematic in a card present environment. We have had customers run the transaction through on a company card and the credit the credit card immediately after.

There is a real need to confirm live account settings for all card types. Visa/MasterCard may work but Discover or AMEX. Address validation, CVV validation cannot be done completely as test transactions of as test accounts.

I am not a QSA either, but my understanding this is acceptable by PCI DSS and by your gateway/processor. You want to make sure you do not reverse too many transactions as you may trigger an alert related to too many reversals, as this can be sign of fraud.