4

.NET 4.5 includes a new validation attribute named as CreditCardAttribute and this attribute specifies that a data field value is a credit card number. When I decompile the assembly which contains this class, I can see the following code for the credit card number validation:

public override bool IsValid(object value)
{
  if (value == null)
  {
    return true;
  }
  string text = value as string;
  if (text == null)
  {
    return false;
  }
  text = text.Replace("-", "");
  text = text.Replace(" ", "");
  int num = 0;
  bool flag = false;
  foreach (char current in text.Reverse<char>())
  {
    if (current < '0' || current > '9')
    {
      return false;
    }
    int i = (int)((current - '0') * (flag ? '\u0002' : '\u0001'));
    flag = !flag;
    while (i > 0)
    {
      num += i % 10;
      i /= 10;
    }
  }
  return num % 10 == 0;
}

Does anybody know which algorithm is applied here to validate the number format? Luhn's algorithm? Also, is this an ISO standard? Finally, do you think that this is the right and 100% correct implementation?

MSDN doesn't provide much information about this. In fact, they have the wrong information as below:

Remarks

The value is validated using a regular expression. The class does not validate that the credit card number is valid for purchases, only that it is well formed.

tugberk
  • 57,477
  • 67
  • 243
  • 335
  • 3
    Looks like an not-so-efficient implementation of [Luhn's](http://en.wikipedia.org/wiki/Luhn_algorithm) – SWeko Sep 25 '12 at 09:54
  • @SWeko thanks! I really don't have much info on the right algorithm. Do u have or know any better way to validate a credit card type in way that it will 100% correct? or is it just impossible? – tugberk Sep 25 '12 at 10:03
  • @tugberk if you're processing payments, the APIs I've used have a pre-auth step which validates the card number and confirms its validity (and probably balance?). You call this, then process your order and approve the pre-auth step. You could use that step to validate the card. – Kirk Broadhurst Sep 25 '12 at 10:05
  • @KirkBroadhurst thanks Kirk! Yes, you are right. The one that I use also have this validation step. However, it would be great to validate this in an early stage and avoid the cost of a network call if this is not a dynamicly changing standard and possible to implement it in a 100% correct way. – tugberk Sep 25 '12 at 10:08
  • @tugberk I don't want to tell you how to write your app, but you'd normally allow to user to progress through the system before getting credit card details as a final step. I do think this is a good question, though. – Kirk Broadhurst Sep 25 '12 at 10:12
  • 1
    @KirkBroadhurst I follow that rule as well. But at the final payment stage (when the user sends the payment inputs), I would like to be able to see (if possible) if the credit card is well-formed or not before going to a different service. As they baked this into the .NET Framework now, I think that this implementation should be 100% correct but I cannot be sure as I have no idea about the standard algorithm. – tugberk Sep 25 '12 at 10:19

2 Answers2

6

The last line:

return num % 10 == 0;

Is a very strong hint that this is a Luhn Algorithm

Jamiec
  • 133,658
  • 13
  • 134
  • 193
3

This algorithm is really a Luhn's algorithm. Unfortunately not all card numbers could be verified by this algorithm so it is not 100% method. However, card numbers of Mastercard and Visa products that allow keyed card number entry should pass this check.

The only 100% way to validate if the card number exist is to perform a transaction. Usually Acquirer Host System protocols used for PoS connections have provisions to validate if the card is not on stop lists and exist in routing tables.

Serge
  • 6,088
  • 17
  • 27