Validating credit card checks
The following steps are required to validate the primary account number (originally excerpted from but that page is no longer active): Step 1: Double the value of alternate digits of the primary account number beginning with the second digit from the right (the first right--hand digit is the check digit.) Step 2: Add the individual digits comprising the products obtained in Step 1 to each of the unaffected digits in the original number.
Step 3: The total obtained in Step 2 must be a number ending in zero (30, 40, 50, etc.) for the account number to be validated.
1 0 4 6 2 2 0 1 8 8 1 4 6 1 0 4 6 2 2 = 58 Using the total (58) you'd take the next highest number that is evenly divisible by ten and subtract the total from this to produce the proper checksum digit (60 - 58 = 2 in this case).
If the total was already an even multiple of ten, say 70, the checksum would simply be zero.
To save a couple of steps in the code, the checksum digit is included in the calculation so that the sum should be an integer multiple of ten.
I was reading 2600 on the bus recently and came across a credit generation algorithms which got me thinking…
Most services will use something called a Luhn Check, which multiplies odd indices by two, sums their digits and then divides the total sum by ten.
If the result of the sum % 10 == 0 then the card number is ‘likely’ to be valid.
This algorithm generates a single digit which is then used as the last digit of the card number. It merely triggers a call to the Java Script function to check the number (you can view the page source to see this for yourself).
if you are building a web application that charges credit cards, at which point would card validation make most sense?
I came to the conclusion that an efficient system, would check the credit card number was valid on the client side.
These may include checking the total number of digits, the number prefix, etc.
The table below shows acceptable values for some of the major credit cards.
Not only does this provide a catcher for data-entry errors, it also doubles as a weak security tool.