Credit Card Number Validation

[neophyte]

Hi Everyone -

Just got a request from a client who wants me to include a credit card input field (as well as expiration date and security code field) on a page in his site.

He doesn't want e-commerce functionality, he just wants to capture this data to an email that would be sent directly to him, and then manually run the information through himself.

Question is: is there any specific (or generic) patterns that I could write a script to check these three pieces of information? The expiration date will be simple enough, but how about the card number?

Do I just need to check the credit card number against a 16 digit numeric pattern? What if they put dashes between each set of 4 numbers? Would that be another pattern?

Does anyone know if the security code on the back of credit cards is only 3 digits long, or do they vary as well?

Is there a tutorial for this someplace? or a very clear explanation of exactly what to do for just capturing the data? It appears to me to be pretty clear, but I just want to check first before I start off.

Thanks in advance to everyone.

Neophyte

[john_k]

When the email is sent to the client, it will be in clear text.

You can do a simple script using regex or other methods to strip any non-numeric characters, so hyphens and/or spaces are easily removed.

The modulo algorithms for checking card numbers can be found with a search in Google.

It is a violation of their merchant agreement to persist, in any format, the CVC code on the back of the card. It is intended to be entered and passed straight through to the card processing service.

You should strongly steer the client away from this method. Although the whole process is a bad idea, the part about the CVC code will leave them liable and subject to termination of their merchant agreement.

[neophyte]

John K -

Thanks for the advice on the CVC. Will advise my client accordingly. If he's doing this manually then I don't think he'll need the CVC code anyway.

Neophyte

[whoisgregg]

Emails are *not* secure. It's foolhardy to use email to send credit card information at all.

[neophyte]

Whoisgregg -

I suspected the security issue of using an email for this sort of thing, but it is because that some third party could intercept the email, or hack the server, to get at someone's information in the email... or that this information would be lying around the clients computer where someone could stumble across it?

This guy is very unsophisticated and cheap so he's afraid of - and doesn't want to pay for - an e-commerce type of solution to process the transaction.

Any advice?

Neophyte

[john_k]

You should hire or partner with someone that knows about setting up eCommerce sites. At a minimum, you should read a few books on the subject.

There are certain industry norms, such as not using email to send credit card information, always using SSL, not persisting CVC data, etc. that a reasonable person would expect. Although every "case" is different, your client leaves themself liable by transacting business on a site that doesn't meet these norms. And if they get sued by a customer or penalized by their bank/cc processor, they are going to turn on you.

[neophyte]

John K -

Okay, point taken. I'll print out your comments and give it to him and then discuss what he REALLY wants to do given the potential liability.

Thanks for your guidance.

Neophyte.

[whoisgregg]

neophyte, in response to your question to me, everything you mentioned is a concern.

john_k has already offered the advice I would offer. :)

[fmouse]

What you want is called the LUHN-10 algorithm. Here's a PHP function which implements it.

## Validate a credit card number using the LUHN formula (mod 10) used by 
## credit card companies. This routine will correctly handle spaces in the 
## number provided and returns validity as true or false. 
## 
function validate($number) { 
 $number = trim($number); 
 $number = eregi_replace("[[:space:]]+", "", $number); 
 $number = eregi_replace("-+", "", $number); 
# Pass 1 
 $j = 0; 
 for ($i = strlen($number) - 1; $i + 1; $i--) { 
 if ((string)(($number[$i] * 2)/2)!= "$number[$i]") 
 { 
 $num2 = "1"; 
 break; 
 } 
 $num2 .= is_int($j++/2)? $number[$i] : $number[$i] * 2; 
 } 
# Pass 2 
 $i = 0; 
 while ($i < strlen($num2)) { 
 $total += $num2[$i++]; 
 } 
# Evaluate 
 if ($total % 10) { 
 return false; 
 } 
 return true; 
} 

I don't recall exactly how to express this in plain English, but basically, every other number is doubled, the numbers are added, and the last digit reflects the result. It's used by all the major credit card issuers, and although banks won't discuss it with you, it's common knowledge. Google for 'luhn' and you'll get lots of results.

[fmouse]

With regard to emailing credit card numbers, I do it all the time on e-commerce websites I build. Here are the basics.

• Any email containing sensitive information must never pass over the public internet unencrypted. If it's generated by a website (SSL context, of course), it must be handed off to a mail server on the same box.

• The vendor using using the site must use POP3 over SSL to retrieve such email, and must clearly understand that such email must be deleted from the server after being downloaded. Your mail server must support encrypted POP3 service.

• Proper attention must be paid to general system security. If you don't understand how to secure your box, you're potentially toast!
  

[PCInk]

Regarding emailing and using terminals to enter the data: the client also needs to inform the credit card company they are currently dealing with that they will be entering orders from the internet into the terminal. They need an 'Internet Merchant Account', not a standard 'Merchant Account'

If a customer phones their card company to do a chargeback and they mention that they placed the order over the internet, the card companies may terminate your standard merchant account. They are allowed to do this as a normal terminal account allows for cardholder present, telephoned, faxed and posted orders, but not for internet transactions.

[dreamcatcher]

This article might be useful:

[sitepoint.com...]

dc