Making sense of your credit card(mint.com)
mint.com
Making sense of your credit card
http://www.mint.com/blog/trends/credit-card-code-01202011/
6 comments
The original was posted a few days ago, http://www.mint.com/blog/trends/credit-card-code-01202011/ this article really doesn't add anything.
I feel I'm being moronic, and will come back to this in an hour or so once I've finished some work and do the maths again... but I've checked with four cards (two credit cards, two debit cards, all VISA) and none of them result in a number divisible by ten. Results were 107, 98, 107, 106.
Having read http://en.wikipedia.org/wiki/Luhn_algorithm I'm either doing it right, or I'm way more tired than I thought. Each card number is 16 digits long, so for (from the left) digits 1, 3, etc. I double them, then I add the sum of those doubles to digits 2, 4, etc.
i.e.
EDIT: Here is an old card number (card is long expired), and to be safe I've swapped various numbers around (but only swapped even position numbers with each other, and odd position numbers with each other, so it shouldn't effect the check sum). Could someone kindly tell me if I'm being an idiot?
Having read http://en.wikipedia.org/wiki/Luhn_algorithm I'm either doing it right, or I'm way more tired than I thought. Each card number is 16 digits long, so for (from the left) digits 1, 3, etc. I double them, then I add the sum of those doubles to digits 2, 4, etc.
i.e.
1234 1234 1234 1234
Would be: ((1 * 2) + 2 + (3 * 2) + 4) * 4
I feel really dumb for writing that out given it's already written out in this article, and on Wikipedia, but either I am being really dumb or my four cards are all invalid.EDIT: Here is an old card number (card is long expired), and to be safe I've swapped various numbers around (but only swapped even position numbers with each other, and odd position numbers with each other, so it shouldn't effect the check sum). Could someone kindly tell me if I'm being an idiot?
5658 4612 3826 9730I think you've forgotten to reduce individual sums mod 9 (i.e., by adding digits) before adding them up.
5658 4612 3826 9730 [original number]
10 6 10 8 8 6 2 2 6 8 4 6 18 7 6 0 [double alternate digits]
1 6 1 8 8 6 2 2 6 8 4 6 9 7 6 0 [digit sums]
16 18 24 22 [sums of groups]
80 [overall sum]
Of course you don't need to bother with the sums-of-groups step; that was just to make it easier for you to notice if I made any mistakes.I was under the impression that credit companies relied on the insanely big number of possible combinations in order to protect them selves. You can surely create a billion "valid" credit card numbers but the probability of a portion of them being in-use is very low.
I'm pretty sure the name and expiration date if not the security code on the reverse side come into play as well.
That's a weird way of doing checksums. Summing digits preserves residues mod 9, yet the final check is mod 10. Weird.
(Now how do the 3 additional verification digits on the back work?)
(Now how do the 3 additional verification digits on the back work?)
They're generated independently of the card number and, in principle, known only to the card issuer and verifiable only by asking them. Merchants are supposed never to record them.
(They don't really need to be independently generated for each card; instead they can be computed from the card number, expiry date, etc., using a secret key known only to the issuer and some cryptographic magic.)
(They don't really need to be independently generated for each card; instead they can be computed from the card number, expiry date, etc., using a secret key known only to the issuer and some cryptographic magic.)
I wrote this for a site I worked on. It uses prototype.js.
https://gist.github.com/271597
https://gist.github.com/271597