Test Credit and Debit Card Numbers: Frequently Asked Questions
Why test credit and debit card transactions?
When you build a payment transaction system, it’s important to ensure that it is working properly.
That said, no developer wants to actually execute real transactions through an existing, valid credit or debit card, then have to go to the trouble of reversing each payment. As a result, all card issuers accept certain numbers as testing accounts, allowing you to validate logic without actually transferring currency from one account to another.
Why can’t developers simply use random numbers?
Most credit card numbers are created using the well-understood Luhn algorithm. In principle, you could create valid 16 digit strings, which would pass the Luhn check - but, of course, they would likely not correspond with a valid credit card number, account owner, or CVV code, and thus would simply result in payment failures at the processor end.
Equally importantly, credit and debit card numbers contain within their very construction valuable information. The first digit tells you about the industry or card issuer: an initial 4, for instance, tells you that the card is a Visa, while a 6 would indicate a Discover card. The next 5 digits identify the institution that issued the card. Thus, to be sure that your payment transaction system is operating as designed, you need to provide it with credit or debit card numbers that test its ability to handle a broad array of brands, issuers, and institutions.
What are some example credit and debit card numbers I can use for testing?
Payment processing platforms sometimes offer proprietary numbers, which will get caught in their systems and avoid an actual call to the card networks. However, the best way to test your credit and debit card applications is to use generally-known and accepted numbers, which properly resolve to specific card networks, and which will generate genuine response codes without actually transferring any money.
The following table presents some examples of valid test credit and debit card numbers:
| Card Number | CVC | Brand | Expiration Date |
|---|---|---|---|
| 4242424242424242 | Any 3 digits | Visa | Any valid future date |
| 5555555555554444 | Any 3 digits | Mastercard | Any valid future date |
| 378282246310005 | Any 4 digits | American Express | Any valid future date |
| 6011111111111117 | Any 3 digits | Discover | Any valid future date |
| 3056930009020004 | Any 3 digits | Diners Club | Any valid future date |
| 3566002020360505 | Any 3 digits | JCB | Any valid future date |
| 6200000000000005 | Any 3 digits | Union Pay | Any valid future date |
You may also find additional information about testing Luhn-valid credit card numbers in the Basis Theory developer documentation.
What is the downside of failing to test credit and debit card number processing?
Payment processing fees tend to be based on a ‘fee-plus’ model, where you will pay a percentage of the transaction, plus a fixed fee. A declined payment transaction will not cost you the percentage, but it will incur the fixed fee - so every failed attempt has a financial penalty.
Can’t I simply let my Payment Service Provider validate credit and debit cards?
Certainly, platforms offering payment services (PSPs) have their own builtin systems for testing and validating credit and debit cards. Vendors who commit all their payment processing to a single platform will benefit from those capabilities, but, of course, will pay fees that reflect the value of that service.
By contrast, vendors who elect to use a multi-processor strategy are able to arbitrage PSPs, selecting the preferred provider on a transaction-by-transaction basis, using algorithms to select the option that charges the least and/or has the strongest track record of successfully processing payments.
