Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Issue with New Credit Cards Being Refused


homewetbar

Recommended Posts

Hello,

 

I've been running an online store for about a year now and more recently I've had a few customers emailing me saying my site would not accept there Visa or Mastercard. At first I just thought it was the normal problem of people mistyping their credit cards but then I traced there actions and saw this happened to some of them many many times until they just quit. What happens is when they enter their credit card and the cc validation (cc_validation.php I think) refuses their cards saying they are invalid before processing them to see if they are really valid.

 

I think it has something to do with the new gift credit cards or diners club/mastercard cards. Surely others have experienced this? Any ideas on how to fix the validation code for the newer cards?

 

Thanks!

Most Valuable OsCommerce Contributions:

Also Purchased (AP) Preselection (cuts this resource hogging query down to nothing) -- Contribution 3294

FedEx Automated Labels -- Contribution 2244

RMA Returns system -- Contribution 1136

Sort Products By Dropdown -- Contribution 4312

Ultimate SEO URLs -- Contribution 2823

Credit Class & Gift Voucher -- Contribution 282

Cross-Sell -- Contribution 5347

Link to comment
Share on other sites

  • 4 weeks later...
As I understand it, in order to accept gift cards, you must first disable the AVS settings in your payment processor interface. Otherwise the transaction will be rejected.

 

No that is not the problem, don't tell people to do that. You have to just disable the part that says something like if AVS info is not available allow not the entire thing to fix that.

 

This problem however relates to the #s used on the card they are different and hopefully someone can post a solution.

Most Valuable OsCommerce Contributions:

Also Purchased (AP) Preselection (cuts this resource hogging query down to nothing) -- Contribution 3294

FedEx Automated Labels -- Contribution 2244

RMA Returns system -- Contribution 1136

Sort Products By Dropdown -- Contribution 4312

Ultimate SEO URLs -- Contribution 2823

Credit Class & Gift Voucher -- Contribution 282

Cross-Sell -- Contribution 5347

Link to comment
Share on other sites

  • 2 weeks later...
This is an open forum and I'll say what I want to say. If you don't like the answer...fine. If I misunderstood the problem that is my fault.

 

The reason why I said that had nothing to do with spite or me being mean to you. It had to do with you are basically telling people to disable a very important part of credit card verification leaving them wide open to fradulent orders not to mention unqualified transaction fees. But the fix I mentioned in my previous post is only part of the solution the other part is someone needs to figure out how to identify the new credit cards and allow them to be sent to the CC processor for verification, whereas currently osCommerce says they are invalid currently before even sending them to the CC company for verfication.

Most Valuable OsCommerce Contributions:

Also Purchased (AP) Preselection (cuts this resource hogging query down to nothing) -- Contribution 3294

FedEx Automated Labels -- Contribution 2244

RMA Returns system -- Contribution 1136

Sort Products By Dropdown -- Contribution 4312

Ultimate SEO URLs -- Contribution 2823

Credit Class & Gift Voucher -- Contribution 282

Cross-Sell -- Contribution 5347

Link to comment
Share on other sites

I mentioned disabling AVS because it was recommended during the holiday season by a credit card processor. Here is the mesage they sent:

 

 

1 December 2005 Processing Gift Credit Card Transactions

 

In the past few years, the use of pre-paid or gift credit cards (stored-value cards with a Visa, MasterCard, Discover or American Express logo) has grown significantly in popularity. According to the third annual National Retail Federation (NRF) Gift Card Survey, conducted by BIGresearch, card sales will total $18.48 billion this holiday season, a 6.6 percent increase over 2004. The average consumer will spend $88.03 on gift cards or 15.6 percent of their holiday gift budget (http://www.nrf.com/content/default.asp?folder=press/release2005&file=giftcards1105.htm&bhcp=1).

 

With this kind of growth, there is no doubt that your business can greatly benefit from processing gift credit card transactions. However, since a gift credit card is not associated with the recipient?s billing address at an issuing bank, gift credit card transactions may experience Address Verification Service (AVS) rejections.

 

AVS is a valuable fraud-prevention tool that allows you to validate customer billing address information before accepting credit card transactions. However, to allow for the smooth processing of gift credit cards during increased holiday shopping, please take the following steps to verify, and if necessary, turn off the appropriate default AVS setting for their payment gateway account:

 

Log into your Merchant Interface account

Click Settings and Profile in the main menu

Click Address Verification System (AVS) in the Security section

Click to deselect the checkbox labeled Address information for cardholder is unavailable (U)

Click Submit

 

Your AVS settings are now updated to allow the processing of gift credit card purchases with unavailable address information. It is recommended that you reinstate this setting shortly after the holiday season.

 

Your success is our priority, especially at this busy time. Good luck and happy holidays!

Link to comment
Share on other sites

I mentioned disabling AVS because it was recommended during the holiday season by a credit card processor. Here is the mesage they sent:

1 December 2005 Processing Gift Credit Card Transactions

 

In the past few years, the use of pre-paid or gift credit cards (stored-value cards with a Visa, MasterCard, Discover or American Express logo) has grown significantly in popularity. According to the third annual National Retail Federation (NRF) Gift Card Survey, conducted by BIGresearch, card sales will total $18.48 billion this holiday season, a 6.6 percent increase over 2004. The average consumer will spend $88.03 on gift cards or 15.6 percent of their holiday gift budget (http://www.nrf.com/content/default.asp?folder=press/release2005&file=giftcards1105.htm&bhcp=1).

 

With this kind of growth, there is no doubt that your business can greatly benefit from processing gift credit card transactions. However, since a gift credit card is not associated with the recipient?s billing address at an issuing bank, gift credit card transactions may experience Address Verification Service (AVS) rejections.

 

AVS is a valuable fraud-prevention tool that allows you to validate customer billing address information before accepting credit card transactions. However, to allow for the smooth processing of gift credit cards during increased holiday shopping, please take the following steps to verify, and if necessary, turn off the appropriate default AVS setting for their payment gateway account:

 

Log into your Merchant Interface account

Click Settings and Profile in the main menu

Click Address Verification System (AVS) in the Security section

Click to deselect the checkbox labeled Address information for cardholder is unavailable (U)

Click Submit

 

Your AVS settings are now updated to allow the processing of gift credit card purchases with unavailable address information. It is recommended that you reinstate this setting shortly after the holiday season.

 

Your success is our priority, especially at this busy time. Good luck and happy holidays!

 

Right this is only one part of AVS, not the entire AVS as you said earlier:

 

Click to deselect the checkbox labeled Address information for cardholder is unavailable (U)

 

That is correct it needs to be disabled as well as oscommerce must recognize it as a valid cc and currently it does not always, which is why I started the thread. :thumbsup:

Edited by homewetbar

Most Valuable OsCommerce Contributions:

Also Purchased (AP) Preselection (cuts this resource hogging query down to nothing) -- Contribution 3294

FedEx Automated Labels -- Contribution 2244

RMA Returns system -- Contribution 1136

Sort Products By Dropdown -- Contribution 4312

Ultimate SEO URLs -- Contribution 2823

Credit Class & Gift Voucher -- Contribution 282

Cross-Sell -- Contribution 5347

Link to comment
Share on other sites

ok here some suggestions that may help.

 

The cc_validation.php file does a preliminary check at the beginning of the validate() function. The first step would be to enhance that section for the card types you're planning to accept.

 

The 2nd step is at the end of this function when it calls the is_valid() routine. If you use an external gateway like authorizenet for instance they do the validation on their end again, so you could instead of calling is_valid() do a

return 1;

 

Ideally you could modify the algorithm for the number validation of the is_valid() to process the valid ones and maybe add a case for test cards & debugging.

Link to comment
Share on other sites

Hello,

 

I've been running an online store for about a year now and more recently I've had a few customers emailing me saying my site would not accept there Visa or Mastercard. At first I just thought it was the normal problem of people mistyping their credit cards but then I traced there actions and saw this happened to some of them many many times until they just quit. What happens is when they enter their credit card and the cc validation (cc_validation.php I think) refuses their cards saying they are invalid before processing them to see if they are really valid.

 

I think it has something to do with the new gift credit cards or diners club/mastercard cards. Surely others have experienced this? Any ideas on how to fix the validation code for the newer cards?

 

Thanks!

I think some of my customers were complaining about that. Now I understand that it really exists, not that a customer did not enter something right.

Link to comment
Share on other sites

  • 3 weeks later...
ok here some suggestions that may help.

 

The cc_validation.php file does a preliminary check at the beginning of the validate() function. The first step would be to enhance that section for the card types you're planning to accept.

 

The 2nd step is at the end of this function when it calls the is_valid() routine. If you use an external gateway like authorizenet for instance they do the validation on their end again, so you could instead of calling is_valid() do a

return 1;

 

Ideally you could modify the algorithm for the number validation of the is_valid() to process the valid ones and maybe add a case for test cards & debugging.

 

 

Hi,

 

I've been having a problem with valid cards being rejected during the pre-validation for some time also.

 

I just had the problem with a visa card, and the customer gave me their info to process manually.

 

I entered the info manually through authorizenet and the card was accepted without a problem, so the pre-validation procedure is definitely where problem is happening.

 

For now, I've disabled the number validation by commenting out the return code in the first part of the validation function:

// return -1;

 

I then tried to enter the previously-rejected card, and it accepted it without a problem.

 

I'm not sure what the implication is of sending a bad card number to authorizenet, I guess I'll find out if it happens.

 

I'm also not sure what other security pitfall this might introduce, so I'm not recommending this as a permanent solution.

 

Is there any updated card number validation algorithm available?

 

thanks,

 

Ed

Link to comment
Share on other sites

Hi,

 

I've been having a problem with valid cards being rejected during the pre-validation for some time also.

 

I just had the problem with a visa card, and the customer gave me their info to process manually.

 

I entered the info manually through authorizenet and the card was accepted without a problem, so the pre-validation procedure is definitely where problem is happening.

 

For now, I've disabled the number validation by commenting out the return code in the first part of the validation function:

// return -1;

 

I then tried to enter the previously-rejected card, and it accepted it without a problem.

 

I'm not sure what the implication is of sending a bad card number to authorizenet, I guess I'll find out if it happens.

 

I'm also not sure what other security pitfall this might introduce, so I'm not recommending this as a permanent solution.

 

Is there any updated card number validation algorithm available?

 

thanks,

 

Ed

 

 

Thats one way around that but that also means you're sending every number to authorize.net and they're going to hit you with a $0.30 charge everytime they check it. So if your customer mistypes the card or leaves off a number 2 times thats $0.60 x 100 orders = $60 x 1000 orders = $600 it could get very pricy, an updated card number validation algorithm for osCommerce would be far the best if there was one available...

Most Valuable OsCommerce Contributions:

Also Purchased (AP) Preselection (cuts this resource hogging query down to nothing) -- Contribution 3294

FedEx Automated Labels -- Contribution 2244

RMA Returns system -- Contribution 1136

Sort Products By Dropdown -- Contribution 4312

Ultimate SEO URLs -- Contribution 2823

Credit Class & Gift Voucher -- Contribution 282

Cross-Sell -- Contribution 5347

Link to comment
Share on other sites

osc deploys the luhn formula which is basically validate the primary account number in terms of checksum. So say you wanted to validate

 

number 1234567890123456

 

You first inverse it becomes 6543210987654321

Then you check the digits multiplying every other digit by 2 starting from the 2nd digit. So the above becomes:

 

6 10 4 6 2 2 0 18 8 14 6 10 4 6 2 2

 

Now you deduce the sum by adding on a digit basis.

 

6+1+0+4+6+2+2+0+1+8+8+1+4+6+1+0+4+6+2+2 = 64

If the number is a factor of 10 would pass through the validation otherwise it will fail. In this case it will fail because 64/10 has a remainder.

 

That's the basic idea anyways

Link to comment
Share on other sites

Thats one way around that but that also means you're sending every number to authorize.net and they're going to hit you with a $0.30 charge everytime they check it. So if your customer mistypes the card or leaves off a number 2 times thats $0.60 x 100 orders = $60 x 1000 orders = $600 it could get very pricy, an updated card number validation algorithm for osCommerce would be far the best if there was one available...

 

Yes, that is an issue. For now I'd rather risk the extra cost in order not to lose a sale, but it would be much better to have the correct info in the validation check.

 

Thanks,

 

Ed

Link to comment
Share on other sites

In the previous discussion about new card numbers, no one was able to turn up any news about changes in the algorithms. Without being able to see the numbers themselves, no one can do anything about fixing this problem. Obviously, don't post the full numbers here, but if you post some relevant information about them, perhaps this problem can be solved.

 

If it's a MasterCard or American Express, tell us the first two digits and how many numbers total.

 

If it's a Visa, tell us the first digit and how many numbers total.

Please use the forums for support! I am happy to help you here, but I am unable to offer free technical support over instant messenger or e-mail.

Link to comment
Share on other sites

Thats one way around that but that also means you're sending every number to authorize.net and they're going to hit you with a $0.30 charge everytime they check it. So if your customer mistypes the card or leaves off a number 2 times thats $0.60 x 100 orders = $60 x 1000 orders = $600 it could get very pricy, an updated card number validation algorithm for osCommerce would be far the best if there was one available...

what difference does it make? I mean the checksum algorithm its straight forward. So someone could generate a fake number and bypass the algorithm anyways. You could ask authorizenet what happens in such cases. But whether you call the is_valid() method or not makes little difference. The digit validation in the validate() method is more important for the filtering.

Link to comment
Share on other sites

what difference does it make? I mean the checksum algorithm its straight forward. So someone could generate a fake number and bypass the algorithm anyways. You could ask authorizenet what happens in such cases. But whether you call the is_valid() method or not makes little difference. The digit validation in the validate() method is more important for the filtering.

 

It makes a difference because people who are not trying to mislead you misenter their cc information so authorize.net slaps you with a fee everytime. So if you can eliminate 50%-75% of those mistyped cc #s it is definately worth it to save the fees... However we still never want to reject valid cc numbers...

Most Valuable OsCommerce Contributions:

Also Purchased (AP) Preselection (cuts this resource hogging query down to nothing) -- Contribution 3294

FedEx Automated Labels -- Contribution 2244

RMA Returns system -- Contribution 1136

Sort Products By Dropdown -- Contribution 4312

Ultimate SEO URLs -- Contribution 2823

Credit Class & Gift Voucher -- Contribution 282

Cross-Sell -- Contribution 5347

Link to comment
Share on other sites

However we still never want to reject valid cc numbers...

 

Only the bank can verify it really. If you think about it is like having a cc machine and comunicate with the bank in real-time. You could deploy a machine at your office and do the process instead of using the gateway. I don't know all the account options authorizenet has.

 

Also one other thing. The test card numbers authorizenet documents will likely fail the validation because of the number of digits mismatch. So you could deploy a global cc test switch of the osc. If the test switch is on you could skip the validation functions.

 

Now if you come accross a cc that fails the osc validation check where it fails. Are you certain it fails because of the checksum algorithm? Or it's simply a number that's not supported?

 

When it fails the checksum it should post the error of TEXT_CCVAL_ERROR_INVALID_NUMBER string otherwise it posts the unknown card error. Which one you're seeing?

Link to comment
Share on other sites

If you all will post the information I requested above, we'll at least be able to see if the basic number format is different.

Edited by dynamoeffects

Please use the forums for support! I am happy to help you here, but I am unable to offer free technical support over instant messenger or e-mail.

Link to comment
Share on other sites

In the previous discussion about new card numbers, no one was able to turn up any news about changes in the algorithms. Without being able to see the numbers themselves, no one can do anything about fixing this problem. Obviously, don't post the full numbers here, but if you post some relevant information about them, perhaps this problem can be solved.

 

If it's a MasterCard or American Express, tell us the first two digits and how many numbers total.

 

If it's a Visa, tell us the first digit and how many numbers total.

 

Aparently the folks at Ze_ncart are having the same issue.

http://www.zen-cart.com/modules/ipb/index....showtopic=40144

Link to comment
Share on other sites

After some research, it turns out that Visa really does have a 14 digit card out there along with their 13 and 16 digit cards. The current cc_validation regexp for Visa will reject 14 digit cards but can easily be fixed by changing this line (The first regexp statement, the one for VISA):

 

if (ereg('^4[0-9]{12}([0-9]{3})?$', $this->cc_number)) {

 

to this:

 

if (ereg('^4[0-9]{12}([0-9]{1}|[0-9]{3})?$', $this->cc_number)) {

Edited by dynamoeffects

Please use the forums for support! I am happy to help you here, but I am unable to offer free technical support over instant messenger or e-mail.

Link to comment
Share on other sites

This is actually a better way to write the function above and this one accepts the 15 digit VISA cards that have been reported in the wild:

 

//Accept 13-16 digit VISA cards

if (ereg('^4[0-9]{12}([0-9]{0,3})$', $this->cc_number)) {

 

As long as it passes the Luhn check, this should be enough checking to send it to the gateway.

Edited by dynamoeffects

Please use the forums for support! I am happy to help you here, but I am unable to offer free technical support over instant messenger or e-mail.

Link to comment
Share on other sites

Now if you come accross a cc that fails the osc validation check where it fails. Are you certain it fails because of the checksum algorithm? Or it's simply a number that's not supported?

 

 

Valid cards are being rejected.

 

To check this, I had a customer give me their info because they were unable to check out. I tried to check them out but got the invalid card message.

 

I then went to authorizenet and manually entered the transaction in the virtual terminal. The card was accepted.

 

The card was a 16 digit visa beginning with 4625.

 

Ed

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...