PHP Classes

File: YACC.txt

Recommend this page to a friend!
  Classes of matthew heald   YACC (Yet another credit card validator)   YACC.txt   Download  
File: YACC.txt
Role: Documentation
Content type: text/plain
Description: documentation
Class: YACC (Yet another credit card validator)
Validate a credit card and determine its type
Author: By
Last change: Class documentation.
Date: 19 years ago
Size: 9,385 bytes


Class file image Download
YACC: yet another Credit Card Validation class Summary This class provides a single source of validating a credit card number. The class validates:- * That the number is valid, checking it against the Luhn modulo 10 check. * That the Valid From date (if supplied) is either valid, an issue no of 2 digits or null. * That the Valid To is valid. The class will return a text string identifying the card type, such as Mastercard, or Visa Package contents cls_CreditCard.php -implements the class credit_card testccclass.php -test container to prove the class works YACC.pdf -this document Background This class is based on class already published on PHPClasses; sadly I do not have the original authors name to recognise their contribution. The reason that this class was written was to overcome a problem on an existing site. The issue related to the different types of card in circulation and the failings in the card merchant service providers systems. In effect they (the bank merchant service provider) were unable (or unwilling) to identify cards which the site owners merchant agreement excluded them from accepting. It was triggered by the bank providing an authorisation code on a cardholder not present (CNP) transaction which they later tried to reject claiming the website owner should have known, was not an acceptable card, despite the banks inability or unwillingness to supply information that could identify rogue cards. The bank intended my customer to carry the cost of the transaction, and any future transactions that they authorised and later decided to renege on (it should go without saying that it couldnt possibly be the banks fault, and therefore someone else should pay for the banks failings). I also experienced problems with the Luhn validation method in the original class; it didnt seem to work as I expected it to. It could well be that it was my fault, rather than the original method, but I felt unable to run with the existing implementation. The card types and names reflect the fact that the Author is UK based, and therefore the card names are the names in use in the UK which may or may not be the same as elsewhere Usage We use the class to perform the following actions:- 1) Check the card number is valid ie passes the Luhn modulo 10 check 2) To identify the card type from the supplied number. 3) Check the Valid From date is less than or equal to today (expressed as mm/yy ie April 2003 is 04/03) 4) Check the Valid To date is greater than or equal to today (expressed as mm/yy ie June 2007 is 06/07) * Therefore by definition you cannot have a valid from date that is greater than the valid to date. If that were to happen either or both will report an error. Note: * The Valid From date is not provided on all cards, therefore null is valid. If you know that you will never handle a null valid from date then it can be safely removed. * The valid from date also acts as an Issue No placeholder for some cards (eg bank ATM / EFT [electronic funds transfer] cards such as Switch. There is however a complication in that not all Switch cards (for example) have an Issue number (some have a Valid From date). * At present most of the sites are also mandated to require a telephone number, and Cardholders name (if the name is different to the person receiving the goods). I would expect you to implement those and any other such checks within the main validation section, not in the class itself. i. As yet the only telephone validation we do is to ensure the number is numeric and at least 11 digits, beyond that I am not aware of any viable validation algorithm. ii. The bank requires the phone number to be a conventional phone number (IE not a mobile / handy / cellular). Although this can be done for UK mobiles (ie those starting with 07, (international +44 7) we ignore that element of the banks requirements. Implementation After including the class in the target script:- Include (..<pathtoclass>/cls_CreditCard.php); Call the class:- <$fieldname>=credit_card::check(<$creditcard>,<$validfrom>,<$validto); Example: $CCData= credit_card::check($CCNo,$VFr,$VTo); where <$fieldname> is the holder of class functions return variable <$creditcard> is the variable holding the credit card number to be checked. This can be either all numeric or including the spacing typed in by the user, the class strips out any non numeric digits in the supplied number. <$validfrom> is the variable containing the Valid From in the form mm/yy OR the Issue No, or nothing (ie NULL). <$validto> is the variable containing the Valid To in the form mm/yy. the credit_card::check function returns a parameter array containing the following:- <$fieldname>[Valid] indicates if the card passes the luhn modulo 10 check <$fieldname>[CanAccept] indicates if the card is acceptable to your installation. <$fieldname>[Index] indicates the card type, see the class for details - count starts from 11, unless it is unknown, in which case it is 0. <$fieldname>[Type] returns a text string identifying the card eg VISA, Switch / Maestro etc.... <$fieldname>[VFr] returns TRUE is there is an error with the Valid From / Issue No, else returns FALSE <$fieldname>[VTo] returns TRUE is there is an error with the Valid To, else returns FALSE For legacy reasons the [Type] parameter starts from 11, or is 0 if invalid (lower numbers were used to identify other payment types. We use numbers below 10 to identify non card based transactions. It is possible for the card number to be valid ie [Valid] = TRUE, and the [CanAccept] to be false and / or the [Type] to be 0, and conversely for the card to be identified correctly but the number fails validation. This will occur where the card is one of the types you have specified as unable to accept OR a type the class does not know about. IE the class may need updating The minimum required to use the class is to check that the card number is valid ([Valid] == TRUE). It is your choice if you implement the other fields, presumably if you wish to implement this class then you do. We check that the card type [Index] matches the card index identified by the customer on the site. IE we get the visitor to select the card they are using from a predetermined list, and validate the [Index] matches the selected card. We use the [Type] for reporting purposes (either on error OR for final receipt). For example the final screen of the transaction identifies the payment method as being Payment method: by VISA Debit card. You can also call Credit_card::clean_no(<$creditcard>) which will return the credit card stripped of any non numeric elements. The other functions can be called in the class, but the intended gateway to the class is: credit_card::check(<$creditcard>,<$validfrom>,<$validto); Testing this class A php script has been included in the documentation (testccclass.php), which implements the credit_card::check method. Apologies for failings in style, I admit to being a PHP non expert. The test script expects the class to be in a child directory ../incfiles you will almost certainly need to modify this path to point to the directory containing the class file. Try it with as many cards a you feel comfortable with. Problems with this class If you experience any problems with the class please let me know by Licence The code is provided as is, there is no claim to copyright or restriction of use, nor is there any explicit warranty or guarantees. I would recommend that you complete as many exhaustive checks as required to satisfy yourself that the code is suitable for your purpose. I cant provide guarantees, or any form of redress (legal, financial or otherwise) should it fail to meet your requirements, however it is used in several web sites with no adverse comments. It is provided on the basis that it may help other PHP developers. Initial Testing The class was developed on a an SUSE Linux 8.2 Professional, running PHP 4.2.2 as a module. phpinfo identifies the kernel as knuth 2.4.19 dated Sept 11, 2002, the PHP version is dated Sept 12, 2002. It has been successfully tested (and runs) on several production servers, all running PHP 4. Final Comment This is the first public PHP class I have released. I do not claim to be an expert in PHP. I have used structures and conventions I am familiar with. The coding style happens to be one I am comfortable with, others may disagree. I am not going to throw my toys out of the pram if someone wants to rephrase the class in a manner that perceived to be more conventional. Given that the class is unlikely to be used in a time critical process I feel that reliability and legibility is better than the most tightly optimised class. References Document identifying valid credit card number ranges as at Sept 2003 URL explaining the implementation of the Luhn Modulo 10 check URL: