How does the generic credit card module "verify" card numbers?

[LRS]

How does the generic credit card module determine if a card number is valid or not? (or is that a secret?)

We have decided to go manual on all our credit card processing due to the huge increase in fraud attempts lately, so we turned off the authorize.net module and turned on what I will call the generic credit card module since I don't know the proper term for it, and now process all charges manually.

How the heck does it know if a card number is valid or not since it isn't really processing anything, just storing it so it can be manually processed? I used a real credit card number to test it and only changed one or two numbers at the very end, and it said it was invalid.......

From what I can see the expiration date and code don't matter as long as the date is not in the past, but I am really curious why it rejects the number when I only changed one number at the end of the card number.

[yellow1912]

How does the generic credit card module determine if a card number is valid or not? (or is that a secret?)

We have decided to go manual on all our credit card processing due to the huge increase in fraud attempts lately, so we turned off the authorize.net module and turned on what I will call the generic credit card module since I don't know the proper term for it, and now process all charges manually.

How the heck does it know if a card number is valid or not since it isn't really processing anything, just storing it so it can be manually processed? I used a real credit card number to test it and only changed one or two numbers at the very end, and it said it was invalid.......

From what I can see the expiration date and code don't matter as long as the date is not in the past, but I am really curious why it rejects the number when I only changed one number at the end of the card number.

I believe there is a module in the addon section that can partly help to reject invalid numbers (based on the pattern used by each card provider etc...)

However, at the end it is totally up to you. Usually your payment gateway should help you with that.

[fairestcape]

The C-Card module uses the LUHN ALGORITHM (Mod Ten Algorithm) to verify is a card number is CORRECT.

Google LUHN ALGORITHM for an explanation.

It cannot verify if the card is being legitimately USED.

If you use this module, how are you going to clear payments?

Make sure you do not violate your agreement with your bank by taking card numbers on-line.

(Lots of posts on this issue on the forum).

[LRS]

OK cool. Now I can sleep at night on that one. I figured it was some kind of pattern that was used.

As for processing, we are set up to have the customer enter their credit card info at checkout online. This is not working out as there are too many fraud attempts.

What do you mean by "taking card numbers on-line" ?

Is there a problem with using the generic cc module to get the information from the customer, then processing it manually on the authorize.net site as long as the card number is split off to a different email address and not stored in full in the database?

How about having the security code stored then deleted once the card has been manually processed?

If that type of a setup is not allowed by Authorize.net then we will have to shut down the credit card module entirely and tell them to call us with the info.

[yellow1912]

Do you know that, with authorize.net, you can simply let the CC number to be collected and sent to Authorize.net, but you will do the actual charge manually on Authorize.net site?

[LRS]

The problem is this.....

Due to large dollar fraud attempts we will no longer ship higher dollar orders until we do the following

Check the verification information from the manually keyed in charge after it has been processed by us on authorize.net
If the address "numbers", zip and cvv don't match we won't ship

We then contact the card holders bank to verify that the FULL address we are shipping to is what they have, that the card holder name is the correct name that they have and that the telephone given by the customer is the one that they have. This REQUIRES that we have the full card number which we cannot get if we let the gateway process it unless I am missing something.

If the phone number doesn't match, we then contact the customer and tell them to give us a phone number that is on their credit card billing records. If they won't or can't, we won't ship. If they do give us the number, then we go again and verify it with the card issuing institution and we call them back at that number to talk to the card holder.

It is a pain in the behind to say the least but if we lose ONE large sale to fraud it will set us back big time. Two or three would possibly put me out of business.

I really do not want to have to have every customer call me and give me their entire credit card info over the phone for every order. It is a time consuming process and it is too easy to enter the information incorrectly when taking it down over the phone.

I am at a loss to figure out some other way to do this if the method I am now using is not OK.

[BREZ]

Would be a LOT simpler to just use google checkout or similar!

[LRS]

Would be a LOT simpler to just use google checkout or similar!

The majority of my customers do not want to use or do not have google checkout or paypal.

Our sales increased 110% when we added direct credit card use without having to go through a secondary party. They simply go to the competition if they can't use their credit card directly.

Our monthly fees also went down several hundred dollars even with the increase in sales.

[fairestcape]

Conor Kerr has written an off-line C-Card module that is more comprehensive that the ZC standard C-Card module.

Look here

[LRS]

Conor Kerr has written an off-line C-Card module that is more comprehensive that the ZC standard C-Card module.

Look here

That looks nice. Thanks.

I am assuming that module will be in compliance with the rules from Authorize.net?