Day 30 of 30 days of ecommerce testing is all about the cards:
Find 4 different types of credit cards and learn what makes them different - e.g. number length.
Since I work in payments I’m going to be a know-it-all and take this question a little further. Why talk about only 4 types of cards when can do them all by talking about BIN ranges? Actually, I learned something new while looking at this from a very nice blog post which is that there is also a checksum built into credit card numbers.
Basically the card number is 3 parts:
- BIN (Bank Identification number) or IIN (Issuer Identification number) 6 digits
- Account number (6 to 9 digits)
- Check digit (last digit)
The math on the check digit is pretty cool and is left as ‘an exercise for the reader.’ As far as the BIN, Wikipedia has a complete (as far as I know) list of BIN ranges and card number digit lengths:
https://en.wikipedia.org/wiki/Payment_card_number#Issuer_identification_number_(IIN)
-Dave K
3 Likes
You beat me to what I was going to say. The wiki page is a good start but lots more in depth data could be added in there.
We have a spreadsheet that calculates the Luhn for you 
4 Likes
If you’re stuck for test cards, usually the following card numbers work on any test system / sandbox:
- 4111111111111111 (visa)
- 4242424242424242 (visa)
- 5555555555554444 (mastercard)
They are valid card numbers (i.e. the right length & they pass the Luhn check) and easy to remember.
The four different types of credit card are:
- Mastercard
- American Express
- Visa
- Diner’s
1 Like
I’ve just discovered this hidden away on my trello board which could be very useful for people in the future
1 Like
@mate.marjai Hey I learned something based on your post!
So I started wondering "Will our sandbox let anything through if it satisfies the algorithm and has the right number of digits and starts with the right number?)
So first I played around with the algorithm on paper and came up with a crazy number (43431414321193876) and… my terminal IMMEDIATELY declined it without even contacting the payment processor (we use Chase here). hmm
Turns out I just did it wrong. I was starting at the rightmost digit and doing every other digit, rather than SKIPPING the rightmost digit and checking any other digit.
So I did it again, this time in excel, and realized it was easy to come up with patterns like 4259595959595959 or 4267676767676767 and they satisfy the algorithm. Ran these into my terminal aannd…
Transaction declined. HOWEVER it did pass through the terminal.
So what I learned is that my terminal knows to check the algorithm, but that our sandbox still needs this to be a valid card on record somewhere. Your numbers above worked, even though I never saw them before, but they must be there somewhere.
cool!
3 Likes
Most terminals will have this very simple check applied before sending any data (in some cases they test for expiry dates as well).
These 3 numbers are the the “go to test numbers” when it comes to payments testing, then many providers would have a list of their own. Usually means they have a white list of numbers they know how to handle in a test scenario, and have some sort of a default one for the rest.
2 Likes