The credit cards or payment card testing most of the time requires you to have a valid set of test data on your backend / stub / test payment gateway. This can sometimes be challenging in Exploratory Testing / Session Based Testing approach as you might not have had upfront preparation to build your test data sets. Similarly on more traditional setup test data might come in too late or just purely wrong.
This is how it usually goes, tell me you have seen this in your organisation. You have your test strategy to outline the high level test approach, you document it in your Test Plan. Section in the test plan talks about test data and about the process of obtaining it. The process usually is that a test data request is a deliverable of the test team and to be send well
in advance to backend provider so that they can build their matching test data in time. Thats all good on paper and as an approach, but what usually happens is that when the test data request is needed, testers are unsure what credit card / payment card types there are, what are the valid card numbers for different types of card issuers and how to identify different error / edge cases tested. A
The solution, you should plan to have a good test coverage across all common credit card providers and also types of common payment related transactions. First have a look at the common credit card numbers below that all pass the Luhn check (e.g. card number validation rules). Then make sure you also have set of #TestObjectives for common edge/error cases.
Example dummy test credit card numbers for all major card providers: