Eeek. I ran into a weird situation today where I ended up with an order placed by our customers that went through even though the order failed due to an invalid credit card. This turned out to be a bug in my own code (if/else if mismatch) that allowed a declined order to happily process as an Approved order.

But the real kicker is that the credit card passed 2 different Mod10 filters before actually passing to the credit card processor which correctly failed the card for processing. As it turns out this odd combination is what caused my code to fail.

Credit Card numbers are always supposed to be Mod10 compliant (although I’ve seen cards in the past that are not! Very, very rare but it has happened!), but of course Mod10 checks are no guarantee that a card is actually a valid credit card. Mod 10 is basically a simple algorithm that adds up numbers and builds a checksum value, but it’s Mod10 based so 1 in 10 numbers will work with it. Additional checks for the first few numbers that are valid credit card numbers are usually added to check for the main credit cards.

Mod10 by itself is more of a quick check for the user so that processing doesn’t have to go to the processor for full processing. In my app I use Mod10 on the client with JavaScript code (from here with some minor modifications) that pops up a non-modal tooltip, which lets customers know right away that they’ve entered an invalid card while they’re typing. However, due to the possibility of non-mod cards (rare as it may be) I do allow the value to be passed to the server and passed off for processing with the Authorize.NET which is my CC processor.

It seems these last few days I’ve been fighting a number of these kinds of very rare code paths that are causing some minor disruption in various applications. Must be that time of month I guess… <g>