October 23, 2005
Luhn formula
A credit card number must be from 13 to 16 digits long. The last digit of the number is the check digit. That number is calculated from an algorithm (called the Luhn formula or MOD 10) on the other numbers. This is to spot typos when a user enters a number, and I assume was to allow detecting an error reading the magnetic stripe when a card is swiped.
The MOD 10 check does not offer security, it offers error detection. Think of it as fullfilling the same role as a CRC in software.
To calculate the check digit:
- First drop the last digit from the card number (because that’s what we are trying to calculate)
- Reverse the number
- Multiply all the digits in odd positions (The first digit, the third digit, etc) by 2.
- If any one is greater than 9 subtract 9 from it.
- Sum those numbers up
- Add the even numbered digits (the second, fourth, etc) to the number you got in the previous step
- The check digit is the amount you need to add to that number to make a multiple of 10. So if you got 68 in the previous step the check digit would be 2. You can calculate the digit in code using checkdigit = ((sum / 10 + 1) * 10 – sum) % 10
For an example of this in practice download the code to the credit card number generator.
Credit card numbers are a special type of ISO 7812 numbers.
Feed
RSS / Atom feed
Free Credit Cards (kind of) | Villager With Wheel said,
April 19, 2008 at 05:54
[...] number” means reverse the whole credit card number. The Darkcoding site explanations right here and right here as well as the Wikipedia explanation here help clarify what is going on. The [...]
Rand Al’Thor said,
January 20, 2008 at 21:09
though this is a bit freighting, its fun to see things like this everyday. its not everyday you get a funny bunch like this
thanks John
James Brown said,
September 3, 2007 at 22:45
It would seem to me that step 7 of your algorithm is overly complicated. Let me suggest three alternatives to make the algorithm simpler.
1. If you insist on calculating and comparing to the check digit removed in step 1, then this calculation seems simpler: 10 - (sum % 10).
2. An even easier solution is to add in the check digit removed in step 1 and confirm that the sum % 10 == 0.
3. One more simplification presents itself if you opt for solution 2 above. Simply do not remove the check digit at all (skip step 1), change step 3 to double all the digits in EVEN positions, and change step 4 to add in the digits in ODD positions. With these changes the new instructions become …
# Reverse the number
# Multiply all the digits in even positions (The second digit, the fourth digit, etc) by 2.
# If any one is greater than 9 subtract 9 from it.
# Sum those numbers up
# Add the digits in odd positions (the first, third, etc) to the number you got in the previous step
# Confirm that the sum is an even multiple of 10. You can do this in code with something like (sum % 10) == 0
- James
Tamlyn Rhodes said,
March 31, 2007 at 12:52
Thanks for this! I thought I’d found a clever way to human-readably encrypt my credit card number in an email by multiplying it with a number that only me and the recipient knew. However it turns out that due to the luhn-induced redundancy it is trivial to retrieve the factors from the product. Drat!
anon said,
November 9, 2006 at 21:29
Thanks for the info, this helps me alot with the e-commerce site that I’m making for my work right now. And it also gives me a laugh reading through the comments
blessyn said,
August 11, 2006 at 15:44
am not good at maths pls
John Banshee said,
April 25, 2006 at 21:28
Hi,
Thanks for this - very useful when developing eCommerce and don’t really wanna use my personal CC number he-he.
Regards
JB
V_Man said,
March 3, 2006 at 22:42
Very interesting and educational site, nice to know a little bit of how this stuff works, good work,
please post more information as you find out.
me said,
January 18, 2006 at 14:23
Howard Beale, I think the reversing has to do about credit cards with 13 digits for example…
If you drop the last digit and do not reverse, you will get the numbers witch were suposed to multiply by 2 (the odd positoion ones) not multiplyed and vice versa… Off course, there are many other ways to deal with this, reversing is just one of them
PS: Sorry my english :-S
MTN Thief said,
December 22, 2005 at 02:19
A differenct formular applies to Rcarge cards. That is my area of specialization. MTN have been on their knee only to know my whereabout and arrest me, maybe kill me. I will continue to destroy the company until they begin to do the right thing. Wanna join my syndicacy? Dangerous but lucrative…send me an email, eetracy2003@yahoo.com. Let me have your number and we can talk. But it must cost you something…SOMETHING…ready?…
Howard Beale said,
December 4, 2005 at 20:13
Actually, according to the information above and my own personal experimentation, you can save yourself some coding and processing time by NOT reversing the number when calculating the Luhn check digit. Mathematically, addition wouldn’t matter if the number were reversed or not. The reversing of the digits is therefore a waste of time.
If the length of the numeric string which you’re going to add the check digit to is odd in length then you would double-calculate the digits in the even positions. Likewise, if the string is even in length then you will double-calculate the digits in the odd positions.
I have some source code in Quick/Visual BASIC form on my website which demonstrates that fact. In fact it automatically calculates the correct digits based on the length of the input string and whether or not you want to generate or verify the Luhn check digit. Very simple MOD 2 stuff. ;->
Anyhow, LOVE the website and the redesign. I do miss the hysterical lameness of the classic posts by the lamers though (I’m sure they’ll be new ones by the terminally clueless).
Perpetually mad as hell at spammers and scammers…
–Howie
Ebuka said,
November 4, 2005 at 17:04
Does Lunh’s formula apply to all cards number (recharge cards)