Skip to content

    Test Credit and Debit Card Numbers: Frequently Asked Questions

    test debit and credit card numbers

    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.

    Want Product News & Industry Updates?

    Subscribe to the Basis Theory blog to get updates right in your inbox