48

I was renewing my Internet subscription through the online portal of my ISP. What struck me was when I was entering my credit card details, I entered the type of my credit card (MasterCard, Visa, AA, etc), and when I entered the numbers, there was one number that I entered wrong. When I pressed the submit button, the website automatically gave me an error that the card number I entered was invalid. I sense this was done locally in the browser and no data was pushed and checked on a server and a reply sent back.

Is there any sequence of numbers each vendor has? Otherwise, how would the website (locally) know about the wrong number?

Rodrigo de Azevedo
  • 242
  • 2
  • 13
tony9099
  • 779
  • 1
  • 5
  • 10
  • 21
    Because a CC number isn't really a single number, it has internal structure. For example the first digit denotes the type of company the issuer is e.g. Amex is 3 because its really a travel agency, not a bank, which would be 4 or 5. The next digits for Amex must be a 4 or a 7. And so on and so on. – Gaius Feb 16 '15 at 16:08
  • 1
    My understanding with visa/MC was the first 2 groups denoted what card it was the second group denoted bank and last group denoted account. – Virusboy Feb 16 '15 at 21:51
  • 2
    FYI, there are several test credit card numbers available. For example here: https://www.merchantplus.com/help/logos-test-numbers/ – powtac Feb 18 '15 at 15:57

5 Answers5

72

Checksums

CC numbers, as well as pretty much any other well designed important numbers (e.g. account numbers in banks) tend to include a checksum to verify integrity of the number. While not a security feature (since it's trivial to calculate), a decent checksum algorithm can guarantee to always fail if (a) a single typo was made or (b) two neighbouring digits are swapped, which are the two most common errors when manually entering long numbers.

http://rosettacode.org/wiki/Luhn_test_of_credit_card_numbers is an example of such a test.

Issuer

If a CC number is technically correct, it may still be not a real CC number. The method for verifying that is simple and complicated at the same time - generally, if you have appropriate access you are able to the look up the issuer institution for each range of card numbers, and then you ask the issuer[s card systems] if they think that this is a valid card. Well, the second part generally happens as a part of making a CC payment, but verifying the issuer is sometimes done before that as an extended test; but not on the client browser.

Peteris
  • 8,369
  • 1
  • 26
  • 35
  • 11
    As an example of "technically correct", the Visa-ish card number 4111-1111-1111-1111 passes the Luhn test, but is clearly not real. – Bobson Feb 17 '15 at 12:44
  • @Bobson I'm pretty sure that's a test number. – MiniRagnarok Feb 17 '15 at 15:32
  • 13
    @MiniRagnarok - Yep. It's the standard test for Visa specifically because it *does* pass Luhn. – Bobson Feb 17 '15 at 15:34
  • Typically, if the ISP intends to actually charge the credit card, they will authorize a small amount on it (e.g. 1 USD). This will not reduce the balance but serves as a quick indicator, taking about a web request's time, if the card is actually valid, given that the card's bank need to confirm the authorized amount. This is often done after checking the syntactical validity of the card to significantly reduce the chances of bouncing credit cards. – Holger Just Feb 19 '15 at 11:47
40

In the United States, they use the Luhn algorithm:

http://en.wikipedia.org/wiki/Luhn_algorithm

How the algorithm verifies a number:

  1. From the rightmost digit, which is the check digit, moving left, double the value of every second digit; if the product of this doubling operation is greater than 9 (e.g., 8 × 2 = 16), then sum the digits of the products (e.g., 16: 1 + 6 = 7, 18: 1 + 8 = 9).
  2. Take the sum of all the digits.
  3. If the total modulo 10 is equal to 0 (if the total ends in zero) then the number is valid according to the Luhn formula; else it is not valid.

How to calculate the check digit:

The check digit is obtained by computing the sum of digits then computing 9 times that value modulo 10. In algorithm form:

  1. Compute the sum of the digits (after doubling every second digit).
  2. Multiply by 9.
  3. The last digit is the check digit.

Example:

Number: 4321-5678-7531-456x (where x is the check digit).

1. Number:              4   3   2   1   5   6   7   8   7   5   3   1   4   5   6   X
2. Double every second: 8       4      10      14      14       6       8      12
3. Sum digits >9:       8   3   4   1   1   6   5   8   5   5   6   1   8   5   3
4. Sum all digits:      8 + 3 + 4 + 1 + 1 + 6 + 5 + 8 + 5 + 5 + 6 + 1 + 8 + 5 + 3 = 69

5. Multiply sum by 9:   69 x 9 = 621
6. Take value mod 10:   621 mod 10 = 1  =>  x = 1

The check digit is 1 and the comnplete valid number is 4321-5678-7531-4561.

If you were to run through the algorithm again to verify the number, then the sum of all digits in Step 4 would be 69 + 1 = 70. Then, 70 mod 10 = 0, so the number is valid according to the algorithm.

EarlCrapstone
  • 517
  • 3
  • 5
  • I tried it on my number and apparently it uses a different algorithm. – tony9099 Feb 16 '15 at 15:59
  • 7
    @tony9099 Actually, using MOD 10, they were running out of valid numbers, so they (the banks) switched to a modified algorithm which uses MOD 5 instead, but the principle is the same. The check digit has to force the entire summed value (as described) to end in either 5 or 0. All cards in the United States use this algorithm, but it is up to the card provider as to if they will use MOD 10 or MOD 5. For example, I'm pretty sure that Diners uses MOD 10, while Visa and Mastercard use MOD 5. – phyrfox Feb 16 '15 at 17:10
  • How can they switch verification algorithms with millions of credit card terminals and software applications in the field that would need to be rewritten with the new algorithm? – Johnny Feb 16 '15 at 21:23
  • 1
    @Johnny terminals and software applications can just use the mod 5 version. Any number that passes the mod 10 test will by definition pass the mod 5 test as well. – user2752467 Feb 16 '15 at 22:24
  • @Johnny This switch happened many decades ago, back when terminals were dumber and would just blindly transmit anything that passed the magnetic check sum from swiping the card. Manual entry was also possible, but those systems did no validation, but instead wasted bandwidth as it phoned home (to a bank, etc) with the invalid number. In fact, I'm pretty sure most terminals today don't assume a valid number is one they can check offline. A few websites use basic validation (e.g. a starting 4 is Visa, and is 16 numbers), but few implement Luhn checking. – phyrfox Feb 16 '15 at 23:14
  • Luhn is widely used, not just in the USA. However, it is not the only immediate checking that can be done without connecting to the authorisation host of the Card Issuer. – MikeRoger Feb 17 '15 at 16:56
7
  1. A lot of sites have client side checks on the CC #. All credit card numbers are about the same length. (As commenters point out, there are several lengths. In general, the lengths are known by the implementor and there is a small set.) There are strings of numbers that relate to each vendor.
  2. From a security standpoint there better be some server side checks too. If you're a pen tester that would be something to check. If you're not, then stay off it because you could get in some big trouble.

https://www.mint.com/blog/trends/credit-card-code-01202011/

Frxstrem
  • 123
  • 4
MrSynAckSter
  • 2,020
  • 10
  • 16
  • 3
    Stack exchange is about staying on topic. This se isn't about every topic on earth. It's ok to let people know that, that's been true on every stack exchange ever. – MrSynAckSter Feb 16 '15 at 16:07
  • 5
    The thing is, this is not Stack Exchange, this is https://security.stackexchange.com/ so my question was related to security. So I think its a valid one. I do not need to be told by you that its not. – tony9099 Feb 16 '15 at 19:26
  • 5
    This is a very valid security question. A long time ago, you didnt need a computer to formulate valid CC numbers. Which is why CCV is now implemented. – Virusboy Feb 16 '15 at 21:49
  • 3
    "All credit card numbers are the same length." - Are you sure? – xehpuk Feb 16 '15 at 23:33
  • 2
    *> [An ISO/IEC 7812 card number is most commonly 16 digits in length, and can be up to 19 digits.](http://en.wikipedia.org/wiki/Bank_card_number)*; AmEx is 15 digits. – Bob Feb 17 '15 at 01:32
  • @Virusboy Your comment "Which is why CCV is now implemented" -- is there a way to pre-verify a CCV? Is it related to the CC # in any way? – tcrosley Feb 19 '15 at 06:14
  • @tcrosley that's something I haven't been able to determine. The factors involved are issuing bank number or RNG from Credit Card issuer. – Virusboy Feb 19 '15 at 14:10
5

Checksums, Card Range Recognition and Length Checks

Most (but not all) card schemes use the Checksum (Luhn) testing described in other answers. However, in addition some algorithms also use (fairly basic) Card Range Recognition (CRR) based on the beginning of the card number (AKA the range). Some also check the card length.

See for example the similarities in many of the various algorithms described at:- https://stackoverflow.com/questions/72768/how-do-you-detect-credit-card-type-based-on-number

Community
  • 1
MikeRoger
  • 150
  • 6
  • Some colleagues recently put me on to http://www.exactbins.com/bin-lookup. They find it more reliable than competing sites. However, I have a caveat: for me it misidentifies ranges we have from UPI, as Maestro rather than UnionPay. – MikeRoger Jul 08 '15 at 08:48
5

Just for completeness: The Luhn algorithm does have one minor flaw.

TL;DR: "the Luhn algorithm detects the transposition of adjacent digits if they are not 09 or 90"

If d1 and d2 are adjacent digits in the credit card number (d1 != d2), then their contribution to the checksum is either f(d1) + d2 or f(d2) + d1, and if transposed they are either f(d2) + d1 or f(d1) + d2. If these two sums are the same or their difference is a multiple of 10, then the checksum does not distinguish between their transposition.

"Credit Cards" 2007, in An Introduction to the Mathematics of Money, Springer New York, NY, pp. 101-112.

The function f(d) is the doubling and sum of digits that might be defined as follows in python for integers d: def f(d): return sum([int(x) for x in str(2 * d)])

There are no two digits that will be zero mod 10 in the above scenario. The proof is tedious, but it can be found in full in the following resource from which I have taken the above block quote.