Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 0.8.6

Request #2194 Incomplete credit card number validation
Submitted: 2004-08-22 22:19 UTC
From: jausions Assigned:
Status: Closed Package: Validate
PHP Version: Irrelevant OS: Irrelevant
Roadmaps: (Not assigned)    

 [2004-08-22 22:19 UTC] jausions
Description: ------------ The type and length of credit card number are not considered when checking for validity. I've created a patch for that: It is backward compatible. New optional parameter for Validate::creditCard(): $cardType to also check against a specific card type. New method: Validate::creditCardType() to validate a card number against a given type. Add test cases. Reproduce code: --------------- The following CC # should fail: 'VISA' => '41111' 'MasterCard' => '5413' 'AMEX' => '3400009' 'JCB' => '21311' 'ENROUTE' => '2014009' 'DISCOVER' => '60110004' 'DINERSCLUB' => '300004' Expected result: ---------------- Numbers returned as invalid Actual result: -------------- Numbers are returned as valid


 [2004-08-23 20:45 UTC] jausions
I've updated the patch file to extract the Luhn algorithm from the creditCard() method into its own method Luhn(). This will help reuse the algorithm for other verifications such as Canadian Social Insurance Numbers. -Philippe
 [2004-12-15 13:03 UTC] dufuz
Note, we don't need BC since we're still in alpha state and would rather not want to clutter the code with some aliases nor BC things. So maybe you could alter the patch with that in mind ? :) Thanks.
 [2004-12-15 16:48 UTC] jausions
Helgi, I'm not quite sure what you are talking about... Are you saying to merge the functionality of the 2 methods creditCard() and creditCardType()...? One verifies if the card number is valid, the other one verifies the type matches... They do two different things. Yes, they could eventually be merged into one creditCard() but we would lose some of the validation feature. Maybe you meant to not have creditCardType(), but a getCreditCardType() method instead in other package... -Philippe
 [2004-12-15 19:07 UTC] dufuz
My mistake then, just read thing wrong, will see if this can make it into the next release. This seems to be good and valid, maybe we'll though move the creditcard code into it's own package, I'm not sure at this stage, since we're moving the country stuff and finance into sub packages.
 [2004-12-17 06:04 UTC] dufuz
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on In case this was a website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. Committed, seems good, added to the validation to check also against things with dashed instead of spaces and just all numbers in a row (no spaces or dashes) Have been thinking about splitting this into it's own packages, seems most logical at this stage, but I'd like to see checks for expire date (see for example) Also checks for the security number( Card Verification Number) if possible ? Last 3 digts above your signature, but American Express has 4 digts above the creditcard number, (above and to the right actually, see paypal for more info) Something you'd be interesting in maintaining/making ? :) Then the creditcard part is very much usable for many shops I'd say :-)
 [2004-12-17 14:36 UTC] jausions
There is no algorithm to check for CCSV code, so it will only need to be added to whatever method at the time of processing of the card. But there is no reason to have that in the Validate package itself. Also, the CCSV code *MUST* not be stored anywhere. This is illegal to store the code for longer than just the current transaction. If the Credit card is not processed immediately, it should be encrypted in whatever backend storage (including session and DB.) We need to find a place in the documentation to put that in, because a lot of PHP programmers don't know that, and this is a huge security problem. -Philippe
 [2004-12-19 04:50 UTC] dufuz
Okey I see. I agree with the doc part, but what about the expire thing I said ? That should be doable, right ? Because if we move this into it's own class, I'd like to see that functionality, and you as a lead/developer, since you know well good deal about this, and it's your code which we're using now :-) I just have to talk to pierre about the seperation and such (please email me at to keep this discussion going, the bug system isn't maybe the best place to talk about this ;)) - Helgi