Sign up ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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.

share|improve this question

migrated from Jul 12 '12 at 20:53

This question came from our site for system and network administrators.

I think your auditor is taking the rule beyond it's intended purpose. The rule is meant to prevent real cardholder data from being stored in test environments. It all comes down to protecting cardholder data. Running a real transaction with real funds is not the same as using a real card number on a test server. I consider this a regular transaction. The fact that you are verifying the information is irrelevant. But I am not a PCI auditor... – Jim G. Jan 22 '12 at 17:19

2 Answers 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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.