"Credit" vs "Debit" Card Number Validation

[JRB-Bldr]

Within my VFP7 application I have been using a standard Luhn10 Credit Card number validation routine when my users enter a Credit Card number. This is a first-level number check to weed out typos, etc., prior to submitting the card number for actual processing and it works for most of the cards.

Obviously this routine only verifies a legitimate number, not the Credit Card itself.

However, my users have received a few Debit Cards which fail the Luhn10 test.
But on some of the cards, the accountant uses the Authorize.Net on-line Credit/Card validation to verify the card and it passes.

The current 'problem' card number results in a Luhn10 checksum calculation sum of 96 -- not a MOD(10) = 0 result. But Authroize.Net passes the number.

Has there been any changes to the Credit/Debit card number validation routine which I now need to take into consideration?

Is there a modification to the algorithm for Debit Cards vs. Credit Cards?

How are any of you accomplishing this task?

Your advice would be most welcome.

Thanks,
JRB-Bldr

 

[Mike Gagnon]

If you have access to Authorize.net why not use them to confirm the validity of the card (debit/credit). There is an option to only verify the validity of the card itself. The problem is with the number of cards out there worldwide the banks will come out with schemes that certain validations will fail. If you need as bit of code sample for checking the validity of a card (not the transaction itself), let me know, I'll dig it up.



Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[JRB-Bldr]

Mike - thanks for the reply.

When I called Authorize.net they told me that they had nothing to do with card validation, they only processed the transactions when they were sent to them by the payment 'gateway' company.

I then tracked down the 'gateway' company and after arguing with them quite a while trying to explain to them that I was not attempting to compromise their security, they told me that they did not do a Luhn10 check. They merely checked the leading card digits and the length of the number, after which they OK'd the card and passed it on to Authorize.net or the bank for them to determine if the card itself was valid or not.

Unfortunately that still leaves me with a few cards which fail the Luhn10 check

http://www.beachnet.com/~hstiles/cardtype.html

while 'passing' the accountant's check.

At which point we are down to arguing which is valid, their OK, or my algorithm's Not-OK.

If anyone else has anything to share which can help me, once and for all, eliminate the confusion, I would be most grateful.

Thanks,
JRB-Bldr

 

[SnyAc]

I don't bother using a pre-authorization card number validity check on my pos systems.... the authorization center simply won't process a transaction with an invalid card number so why put the front-end check in... a swiped card transaction is based on the swipe anyway, and not user entry.

Andy Snyder
SnyAc Software Services

http://www.snysoft.com

 

[JRB-Bldr]

This particular situation is somewhat different because my client bills these customers upon delivery over time instead of billing ahead for a single total amount.

The customer initially signs up and provides a credit card number which is put 'on file'. Then throughout the month the 'product' is created and delivered. This amount may vary from month to month depending on circumstances. At the end of the month (each month) a customer statement is generated stating how much was delivered and how much will be billed against the card.

My client does not want to find out that the card is no good after the product has been delivered. Instead they want to know that there is a very high likelihood that the card is good ahead of time.

I realize that just by knowing that the card number passes the Luhn10 test is no 100% guarantee that the card is GOOD. But it is better than finding out that the customer made the number up in his head or, more likely, someone made a typo.

Thanks,
JRB-Bldr

 

[Mike Gagnon]

JRB-Bldr

Can you explain somthing.
1. You sound like you have access to authorize.net
2. Last I looked, in a merchant's account there is an option to just validate the card with no transactions (either just validate or put the account for testing only.) And this can be done via the interface or via VFP code.

I understand Authorize.net do not validate themselves but they do return the "answer" from the Gateway. So if your validation scheme is not 100% good, why not use one that may be better.



Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.
ReFox XI (www.mcrgsoftware.com)

 

[JRB-Bldr]

Mike -
From my discussions with support personnel at Authorize.net, I was informed that Authorize.net does NOT validate credit card numbers themselves. Their purpose in life is to convert the "gateway" submitted transaction to the appropriate format and then forward it to the appropriate bank for processing, then handle the reverse transaction. They said (at least the person I spoke with) that they, themselves, do not do anything towards validating the card numbers - that's up to the "gateway" provider and the bank.

When I then spoke with the 'gateway' provider to Authorize.net, what they told me led me to believe that their "validation" routine is less reliable than my own Luhn10 validation.

According to them, the "gateway" merely checks the length of the credit card number and the appropriate leading digits. Assuming that those two parameters PASS, they inform the user that the card number is OK.
At that point they quit the validation process and, upon submitting the transaction to the bank via Authorize.net, they rely on the bank to determine if the card number itself is truly Valid or not.

Unfortunately that is where this whole issue came about.
The 'gateway' provider was OK'ing card numbers when the Luhn10 algorithm was failing it. The uncertainty that this difference caused began this entire topic of discussion.

I don't want to enter a 'gateway' OK'd card into our system at the first of the month, deliver product throughout the month, only to find out at billing time at the end of the month that the card transaction is DECLINED.

Yes, merely getting a good validation of the card number itself, will not GUARANTEE that the bank actually issued the card to the individual, but it is at least a partial check and it would catch frequent typo errors which the above described 'gateway' OK would most likely not catch. That is the primary reason for our up-front card number validation.

Thanks,
JRB-Bldr

 

[NasibKalsi]

JRB-Bldr

The simple logic says that:

1. Charge the customer $1.00
2. If passed, then Credit $1.00

Problem may be the credit limit.

Nasib Kalsi

 

[mm0000]

JRB-Bldr

Is the problem debit card a a VISA or MASTERCARD. More information on the debit card provider could provide more clues on what the probelm could be.

 

[JRB-Bldr]

The most recent specific example of a problem was with a MasterCard number. Note that between problem numbers we have many MasterCard numbers & other card-type numbers pass the test.

This particular number did indeed begin with "55" and it was indeed 16 characters long, but it did not pass the Luhn10 Mod10 checksum algorithm check.

But we have had a few other individual cards fail in the past from time to time but I do not remember what type of card(s) they were.

Thanks,
JRB-Bldr

 

[mm0000]

I have worked on applications for a specific a specific credit card issuer which has also included generation of credit card numbers for new customers.

After I read your post, what I am now thinking - what if there was a bug in my program and I generated numbers that failed the Luhn10 test. Coming to think of it - maybe there are no further checks at Card Embossing and it would create valid VISA/MASTER non Lunhn10 credit card numbers. Which may also be why authorize.net does not do the Luhn10 test since the possibility of non Luhn10 numbers exist. Maybe Luhn10 is not a requirement by MASTER/VISA but mosy card companies use it anyway to reduce errors, and some card issuers have chosen their own algorithm - maybe the only relevant part of the card number for MASTER/VISA is the BIN number.

If Lunhn10 is not compulsory you could identify which BINs (first 6 digits) fail the Luhn10 test and create a database for them and dont do the Luhn10 validation for these cards, and if you can identify the validation algorithmn for these cards do a separate validation for these cards.

I had developed these applications 5 - 6 years ago and I will try and contact the credit card company and check whether it is possible to have non Luhn10 valid card numbers.

 

[JRB-Bldr]

mm0000 - I appreciate your input.

IF it is possible that there are VALID credit cards out in the world which fail the Luhn10 MOD10 check, then I might reconsider how my routine works.

At this time it REJECTS the card number upon failing since I was under the understanding that if the card did not pass, it was BAD - that's how I read the information on the various websites around the topic.

But if there MIGHT be some truly VALID cards out there which fail, then I will change my routine to WARN the user, instead of totally rejecting it.

I look forward to any further info you might have to share.

Thanks,
JRB-Bldr