Archive for March, 2013

Strlen issue for numbers

Saturday, March 9th, 2013

There is an issue you must keep in mind when dealing with PHP numeric types.

I was trying to validate a credit card number today, in order to apply Luhn’s algorithm I needed to know the number of digits in the credit card number string.

Let me give you an example:

Credit card number: 4415121641207182

Let’s say I’m using a function.

function luhnsFunc ($ccn){
    return strlen($ccn);

And call it like this:

$ccn = '4415121641207182';
echo luhnsFunc($ccn);

The returned value is: 16

But see what happens when the credit card number is not declared as a string.

$ccn = 4415121641207182; //No quotes
echo luhnsFunc($ccn);

The returned value is: 19

So what’s happening here?!

I did a var dump to each case and found out something pretty interesting.

For the first case I got:

string(16) "4415410012107183"

Which is ok, but let’s see the second case.


So it’s storing a float on scientific notation. Why?

Take a look at this:

Just above the warning you’ll read the following:

The size of an integer is platform-dependent, although a maximum value of about two billion is the usual value (that’s 32 bits signed). 64-bit platforms usually have a maximum value of about 9E18. PHP does not support unsigned integers. Integer size can be determined using the constant PHP_INT_SIZE, and maximum value using the constant PHP_INT_MAX since PHP 4.4.0 and PHP 5.0.5.

The purpose of creating the function is that no matter what I pass it as an argument it will always bring the correct result. Applying the Luhn’s algorithm to a 16 char length string is very different than applying it to a 19 chars length string.

So how do I solve this?

function luhnsFunc ($ccn){
    $type = gettype($ccn);
        case 'string':
            $ccn = number_format($ccn,0,'',''); //The second parameter is a zero
    return strlen($ccn);

An finally the length is correct

Credit card Number validation

Saturday, March 9th, 2013

Credit card validations are very important when it comes to E-commerce.

Most of the time your clearing house will validate the number and return an error message if something went wrong. If your clearing house does the validation it means that the order has already been closed and if your user typed the wrong credit card number he might have to go through the whole sale process again (choose items, fill out credit the card form, perhaps fill out the wrong credit card number again).

If the user is not aware of the error, perhaps after two attempts he’ll quit trying and the sale will be lost.

Let’s think in USABILITY.

If your user realizes he’s typing the wrong credit card number from the moment he’s filling the form, he won’t have to deal with the clearing house coming back with a rejected transaction.

How do you validate a credit card number?

You’ll have to check 2 thing:

  1. Credit card number type 
  2. Luhn’s algorithm

Both of them are important to get a correct validation for you credit card number. Both will help you give great hints to your user in case he’s typing an incorrect credit card number.

Credit Card Type

Most of credit card numbers are built with 4 blocks of information:

  • MII (Major Industry Identifier)
  • IIN (Issuer Identification Number)
  • Person’s account number
  • Check digit

So basically you can start your validations from the very first typed digit and by the time your user has typed the first six digits you can clearly identify the credit card’s issuer. For more information go to:

You’ll see that different industries have a specific IIN assigned to them.

Luhn’s Algorithm

The Luhn’s Algorithm is used to verify that the numbers sequence is valid by doing a checksum of the credit card’s number.

The details of the algorithm can be found here:

The best credit card validation would check both type and check digit to be correct. This is great because perhaps the user types a CCN for a Maestro card while his card is VISA; by means of switching an image the customer may realize something is wrong.

This validations can be done both in client and server side scripts before sending data to the clearing house.