Credit Card Validation via the Luhn Formula--Part 3 of Chapter 7 from Usable Shopping Carts (1/4)
  [next] |
Usable Shopping Carts, Chapter 7: CC Validation and Verification
Validating Credit Card Numbers with the Luhn Formula
[The following is the conclusion of our series of excerpts from the glasshaus title, Usable Shopping Carts.]
The question of whether or not a credit card number represents an active credit or deposit account, and that this account has a sufficient line of credit or balance to cover a sale can only be answered by a clearinghouse or card processor with access to a banking system of which the card's backer is also a participant. However, because issuers of cards follow certain rules when creating card numbers, it is possible to verify whether a given number is accurate or couldn't possibly be a number of the stated type. We can use this information to check a number given to us by a customer and so catch any errors the customer might have made in typing it into the form before we submit it for authorisation.
Each type of card always has a certain number of digits and begins with a given prefix or range of prefixes. The following table provides the prefixes and lengths for the five most commonly used credit cards:
CARD TYPE |
PREFIX(es) |
LENGTH(s) |
MasterCard |
51-55 |
16 |
Visa |
4 |
13 or 16 |
American Express |
34 or 37 |
15 |
Discover |
6011 |
16 |
Diners Club / Carte Blanche |
300-305, 36, or 38 |
14 |
In addition, the number itself can be subjected to a mathematical test (of the sort generally referred to generally as a checksum) which it must pass in order to be legitimate. This test is known as the Luhn formula. It is somewhat tedious to perform by hand, but it's not terribly difficult to write a script to automate the task. These are the steps required to use it:
Double the value of every other digit starting with the next-to-rightmost digit.
If any of the resulting values has more than two digits, then its digits must be added together to produce a single digit.
Add the sum of all the digits not doubled in step 1 to the sum of all the digits resulting in step 2.
If the result is exactly divisible by 10 (that is, if the result ends in a zero), then the number is valid--providing of course that it's of the correct length and bears a correct prefix for that type of card--and can now be submitted for authorisation of a sale.
For example, suppose we're given the number 2323-2005-7766-3554.
2 |
3 |
2 |
3 |
2 |
0 |
0 |
5 |
7 |
7 |
6 |
6 |
3 |
5 |
5 |
4 |
*2 |
- |
*2 |
- |
*2 |
- |
*2 |
- |
*2 |
- |
*2 |
- |
*2 |
- |
*2 |
- |
4 |
3 |
4 |
3 |
4 |
0 |
0 |
5 |
14 |
7 |
12 |
6 |
6 |
5 |
10 |
4 |
4 |
3 |
4 |
3 |
4 |
0 |
0 |
5 |
1+4=5 |
7 |
1+2=3 |
6 |
6 |
5 |
1+0=1 |
4 |
|
SUM: 4+3+4+3+4+0+0+5+5+7+3+6+6+5+1+4=70. 70 mod 10 = 0. |
|||||||||||||||
Of course this number obviously isn't a valid one for any of the types shown due to the prefix, but it serves to illustrate the method used. Now let's put this all together into a workable validation routine. We'll be checking only MasterCard, Visa and American Express numbers in the example, but you should be able to use the information from the table above to extend the validation scripts to cover the additional card types listed, and more are available on the Web (see the References section at the end of the book).
[next] |
Created: January 2, 2003
Revised: January 2, 2003
URL: http://webreference.com/programming/carts/chap7/3/
