Add Luhn validator
merged branch merk/financial-validators (PR #4734)

Commits
-------

6ff9b04 Add Luhn validator

Discussion
----------

[2.2] [Validator] Add Luhn validator

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets:
Todo: Adding documentation if this PR is blessed.
License of the code: MIT

I submitted these validators to JMSPaymentCoreBundle, because they're payment related, but @schmittjoh feels that they're a better choice for adding to Symfony2.

See schmittjoh/JMSPaymentCoreBundle#52 for the original submission.

---------------------------------------------------------------------------

by fabpot at 2012-07-04T05:19:42Z

I'm +1. @bschussek?

---------------------------------------------------------------------------

by shieldo at 2012-07-04T15:46:05Z

+1 in principle (certainly the Luhn check).  I did wonder whether Visa Electron should also be in there (although, that uses a subset of the Visa range, and the chance that you would be checking for a Visa Electron but *not* Visa at the same time is vanishingly small, so maybe this is unnecessary).

---------------------------------------------------------------------------

by merk at 2012-07-04T21:25:30Z

@shieldo I did have a concern about the Electron as well, but in the case of an online system doing payment processing, I'm not sure anyone would ever need to check if it was an Electron card or not.

---------------------------------------------------------------------------

by merk at 2012-07-04T21:28:25Z

We could expand the CardScheme stuff further with this list: http://en.wikipedia.org/wiki/List_of_Issuer_Identification_Numbers

Is there any point expanding the validator beyond financial services and into the other sevices listed?

---------------------------------------------------------------------------

by shieldo at 2012-07-04T21:37:41Z

@merk Yes, in actuality there are always going to be cases you can't trap with a regex - I'd say validation like this is working if it catches a majority of cases of invalid numbers, because in reality ones that get through will just fail downstream anyway. The purpose of the validator isn't to identify individual schemes for numbers, it's to do a sanity check across collections of schemes.

I don't really see any point expanding beyond financial services for a core validator (imho) - I'm not sure how stable some of this information is.

---------------------------------------------------------------------------

by Gator92 at 2012-07-11T00:45:50Z

+1 on the Luhn check (without the authorship, just give credit to Greg Knapp), the CardScheme, however, is not really required by most gateways these days, it's a better candidate for a custom constraint.

---------------------------------------------------------------------------

by merk at 2012-07-11T00:47:20Z

I dont object, but Greg's algorithm has a flaw for odd length creditcard numbers. The unit testing written by Infinite caught this.

---------------------------------------------------------------------------

by Gator92 at 2012-07-11T01:35:46Z

You're right, the Knapp algo is flawed and does not appear to work on odd-numbered length cards.

---------------------------------------------------------------------------

by fabpot at 2012-07-11T05:49:22Z

@merk: Can you open two new pull requests? One for each validator?

---------------------------------------------------------------------------

by merk at 2012-07-26T23:42:24Z

PR updated to remove CardScheme into its own PR.

Documentation PR added to symfony-docs
updated CHANGELOG