Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

[CONTRIBUTION] Authorize Net AIM module


Vger

Recommended Posts

Looking at Austin Renfroe's old AuthorizenetConsolidated_1.7.12.zip (which doesn't store CC numbers) it seems he had made a change in checkout_payment to monkey the fields around in process.

 

Thanks for Vger etc for underlining the perils of card-numbers. Here is a critical message about reverting to SIM and the standard authorize.net module:

 

In brief, it appears that if you have installed any AIM module for authorize.net you cannot go back to the standard osCommerce SIM module without getting Authorize.net to re-set your Response/Receipt urls - this is something you cannot do yourself.

 

I've just had a nightmarish 8 days of lost sales due to a separate sql corruption issue on my server, but while waiting/fuming for my hosting service to restore (or allow me to restore) a backup database, I double-checked my Authorize.net settings - and noticed that settings:Response/Receipt URLs was blank. I looked through the osCommerce forums (there is nothing in the Milestone 2.2 documentation) and found conflicting advice, although catalog/checkout_process.php is "correct". I entered that for both return and relay settings. ...and went on waiting for my database to be restored.

 

When the back-up was restored (at the cost of two weeks' data), PayPal worked perfectly. Authorize.net produced the error message, "There has been an error processing your credit card. Please try again."

 

I realized eventually that this was a problem with the return url settings and --since everything had worked properly before my server problem-- I tried getting rid of them and returning my settings Response/Receipt URLs to blank. When I attemtped a test-mode purchase this returned the error, ""The following errors have occurred. (14) The referrer, relay response or receipt link URL is invalid."

 

With that I contacted an Authorize.net live-chat representative and explained that I wanted to get my Response/Receipt settings restored to their defaults -i.e. before I as the account-holder had entered any information, because deleting them on the settings page did not work. He told me that the catalog/checkout_process.php was correct for AIM, and I said but my module is SIM and ...after a bit more negotiation he was indeed able to restore the defaults quite easily. My settings now LOOK exactly the same as when I had deleted the URLs myself, but my authorize.net works.

 

Perhaps there is a better return page to specify to Authorize.net for the SIM module, but the return setting should obviously be left unconfigured if possible. (I have suggested to authorize.net that they add a user-accessible "clear all settings/return to set-up defaults" option, because once anything has been entered, deleted-and-blank does not mean "none", even though it looks the same.

 

I will try to integrate AuthorizenetConsolidated_1.7.12 AIM later on (Please tell me that the team leaders are already dusting off 1.7.12 and that its thread and support will be back online soon!) but for now I'm just glad to be back in business.

Link to comment
Share on other sites

I'm having a big problem here in the middle of busy holiday sales.

 

I've had numerous people calling to tell me they are getting an error "Card Code Invalid" when the 3 digit code is 100% correct.

 

I tried one of these myself- and it came back with the error "Card Code Invalid...". But here's the kicker, I called Authorize.net and nothing was declined- in fact this order never made it their way to even decline it.

 

I did run that same card thru the virtual termincal with the CVV and worked fine.

 

But, lots of cards are going through... it's very, very odd.

 

I really hope someone can help cause this is costing big holiday sales right now.

 

About this... have been doing HEAVY investigation today... and I've figured out a common thread. If someone enters a credit card CVV that begins with a "0" it will say it's invalid... even when it's not.

 

So, why would it reject CVV's with a start of "0" and how do we fix it?

Link to comment
Share on other sites

About this... have been doing HEAVY investigation today... and I've figured out a common thread. If someone enters a credit card CVV that begins with a "0" it will say it's invalid... even when it's not.

 

So, why would it reject CVV's with a start of "0" and how do we fix it?

 

perhaps "072" is being submitted to authorize.net as "72". an integer or val type truncation?

Link to comment
Share on other sites

About this... have been doing HEAVY investigation today... and I've figured out a common thread. If someone enters a credit card CVV that begins with a "0" it will say it's invalid... even when it's not.

 

So, why would it reject CVV's with a start of "0" and how do we fix it?

I am having the same troubles. Frustrating!!!

 

I am also hoping someone knows how to delete the card numbers from my database after each order is succesful, to meet the requirements of Authorize.net.

Life Is Too Short,

Enjoy Your Coffee!

Pete

Link to comment
Share on other sites

I am having the same troubles. Frustrating!!!

 

I am also hoping someone knows how to delete the card numbers from my database after each order is succesful, to meet the requirements of Authorize.net.

 

Folks- in the past week since have this in here, I have taken over $5k in sales by phone with people having this problem - and they all have card codes that start with zero's... this should be affecting us all- I bet if you try it on yours this will happen.

 

I think that is right about it ignoring the 0 and taking just the other 2 intergers... we need a fix- ITS HOLIDAY SALES TIME!

 

I wish I knew more programming than I do right now.

Link to comment
Share on other sites

Folks- in the past week since have this in here, I have taken over $5k in sales by phone with people having this problem - and they all have card codes that start with zero's... this should be affecting us all- I bet if you try it on yours this will happen.

 

I think that is right about it ignoring the 0 and taking just the other 2 intergers... we need a fix- ITS HOLIDAY SALES TIME!

 

I wish I knew more programming than I do right now.

 

 

temporary fix I would suggest: don't require the CVV in AUTHNET settings

Link to comment
Share on other sites

temporary fix I would suggest: don't require the CVV in AUTHNET settings

 

If I turn it off it still comes up with that error. Weird. Very weird... its like even if you turn it off it's trying to pass numbers anyway.

 

It sucks, but what I've had to do is turn off CVV authorization from Authorize.net so any combo can be used in that area, and put this note in the language file for the error: "Your credit card could not be authorized for this reason. Please try again or try a new card. Special note... if you are receiving a "Card Code" error, and your 3 digit code begins with a "0", please substitute a "1" in the place of the "0"."

Link to comment
Share on other sites

If I turn it off it still comes up with that error. Weird. Very weird... its like even if you turn it off it's trying to pass numbers anyway.

 

It sucks, but what I've had to do is turn off CVV authorization from Authorize.net so any combo can be used in that area, and put this note in the language file for the error: "Your credit card could not be authorized for this reason. Please try again or try a new card. Special note... if you are receiving a "Card Code" error, and your 3 digit code begins with a "0", please substitute a "1" in the place of the "0"."

I tried that and then I get declined by authorize.net with this error code:

This transaction has been declined. - Your credit card could not be authorized for this reason. Please correct any information and try again or contact us for further assistance.

Life Is Too Short,

Enjoy Your Coffee!

Pete

Link to comment
Share on other sites

I tried that and then I get declined by authorize.net with this error code:

 

You have to go into your Authorize.net account and deactivate checking the CVV code, and transactions will go through. I know it opens up fraud, but for the amount of business I know we're loosing (and I don't want to think about the ones I don't know of), it's my only option at this point.

Link to comment
Share on other sites

I know some of you are having real trouble with this, and that it's a bad time of year - but I have to say that there's no way I can even look at this before the New Year. It's a very busy time of year for me too!

 

All that the module does by way of validation is to check if the cvv number is less than 3 digits or more than 4, and if it is it returns an error. If the cvv number provided isn't valid then it's A Net that will flag that.

 

I do wonder if these problems all relate to one particular make of card, which uses zeros in the cvv but only for a certain number range of that card itself which is in a new number range.

 

The reason I say this is that the A Net module checks the card itself against includes/classes/cc_validation.php, and this is an old osCommerce file which is outdated and does not include all the latest release numbers of cards for particular providers. This is the relevant part of what's in that file:

 

class cc_validation {
var $cc_type, $cc_number, $cc_expiry_month, $cc_expiry_year;

function validate($number, $expiry_m, $expiry_y) {
  $this->cc_number = ereg_replace('[^0-9]', '', $number);

  if (ereg('^4[0-9]{12}([0-9]{3})?$', $this->cc_number)) {
	$this->cc_type = 'Visa';
  } elseif (ereg('^5[1-5][0-9]{14}$', $this->cc_number)) {
	$this->cc_type = 'Master Card';
  } elseif (ereg('^3[47][0-9]{13}$', $this->cc_number)) {
	$this->cc_type = 'American Express';
  } elseif (ereg('^3(0[0-5]|[68][0-9])[0-9]{11}$', $this->cc_number)) {
	$this->cc_type = 'Diners Club';
  } elseif (ereg('^6011[0-9]{12}$', $this->cc_number)) {
	$this->cc_type = 'Discover';
  } elseif (ereg('^(3[0-9]{4}|2131|1800)[0-9]{11}$', $this->cc_number)) {
	$this->cc_type = 'JCB';
  } elseif (ereg('^5610[0-9]{12}$', $this->cc_number)) { 
	$this->cc_type = 'Australian BankCard';
  } else {
	return -1;
  }

 

You may want to look in Contributions to see if there is a more up to date version of cc_validation.php which contains all of the latest card issue numbers.

 

Vger

Link to comment
Share on other sites

I know some of you are having real trouble with this, and that it's a bad time of year - but I have to say that there's no way I can even look at this before the New Year. It's a very busy time of year for me too!

 

All that the module does by way of validation is to check if the cvv number is less than 3 digits or more than 4, and if it is it returns an error. If the cvv number provided isn't valid then it's A Net that will flag that.

 

I do wonder if these problems all relate to one particular make of card, which uses zeros in the cvv but only for a certain number range of that card itself which is in a new number range.

 

The reason I say this is that the A Net module checks the card itself against includes/classes/cc_validation.php, and this is an old osCommerce file which is outdated and does not include all the latest release numbers of cards for particular providers. This is the relevant part of what's in that file:

 

class cc_validation {
var $cc_type, $cc_number, $cc_expiry_month, $cc_expiry_year;

function validate($number, $expiry_m, $expiry_y) {
  $this->cc_number = ereg_replace('[^0-9]', '', $number);

  if (ereg('^4[0-9]{12}([0-9]{3})?$', $this->cc_number)) {
	$this->cc_type = 'Visa';
  } elseif (ereg('^5[1-5][0-9]{14}$', $this->cc_number)) {
	$this->cc_type = 'Master Card';
  } elseif (ereg('^3[47][0-9]{13}$', $this->cc_number)) {
	$this->cc_type = 'American Express';
  } elseif (ereg('^3(0[0-5]|[68][0-9])[0-9]{11}$', $this->cc_number)) {
	$this->cc_type = 'Diners Club';
  } elseif (ereg('^6011[0-9]{12}$', $this->cc_number)) {
	$this->cc_type = 'Discover';
  } elseif (ereg('^(3[0-9]{4}|2131|1800)[0-9]{11}$', $this->cc_number)) {
	$this->cc_type = 'JCB';
  } elseif (ereg('^5610[0-9]{12}$', $this->cc_number)) { 
	$this->cc_type = 'Australian BankCard';
  } else {
	return -1;
  }

 

You may want to look in Contributions to see if there is a more up to date version of cc_validation.php which contains all of the latest card issue numbers.

 

Vger

 

The Problem has nothing to do with the CC number: these regexes don't check the CVV

 

I would look in checkout_process.php

 

and look for 9around line 60

 

 require(DIR_WS_CLASSES . 'order_total.php');
 $order_total_modules = new order_total;

 $order_totals = $order_total_modules->process();


 $sql_data_array = array('customers_id' => $customer_id,

 

and give a try to replace by:

 

 require(DIR_WS_CLASSES . 'order_total.php');
$order_total_modules = new order_total;

$order_totals = $order_total_modules->process();

if (strlen($order->info['cc_cvv']) < 3) {$order->info['cc_cvv'] = '0' . $order->info['cc_cvv'] }; // adds a zero if lenght of CVV is less than 3

 $sql_data_array = array('customers_id' => $customer_id,

 

 

 

this logic assumes that AMEX , which has 4 digit CVVs doesn't have a zero first digit

 

Let us know!

Edited by pixclinic
Link to comment
Share on other sites

When I do that it gives an error: Parse error: parse error, unexpected '}' in /home/***/public_html/checkout_process.php on line 58

 

try to add a semi colon before the curly bracket:

 

 

 

$order->info['cc_cvv']; };

Link to comment
Share on other sites

Darn! That did the trick on getting rid of the "}" error... but it didn't fix the problem of what we're dealing with here.

 

Ok we need to know now if this extra zero is passed to Authnet.

 

look in your db if the cvv is stored with the extra zero

Link to comment
Share on other sites

The Problem has nothing to do with the CC number: these regexes don't check the CVV

 

I know that, and that info was in my post. I was simply suggesting that it may be a new issue of card numbers which uses zeros in ccv numbers, and what appears to be a cvv issue may in fact be caused by a card numbering issue.

 

Vger

Link to comment
Share on other sites

I know that, and that info was in my post. I was simply suggesting that it may be a new issue of card numbers which uses zeros in ccv numbers, and what appears to be a cvv issue may in fact be caused by a card numbering issue.

 

Vger

 

let's test first if fixing the cvv and passing it with 3 digits fixes teh problem (which is easy to do). Then, if it still doesn't work, let's work on testing the card issuer (which will be more difficult to code). Does that make sense?

Edited by pixclinic
Link to comment
Share on other sites

I just did a quick fix and a couple test orders and it worked!

 

On line 246

 

x_card_code => $_POST['cc_cvv'] + 0, // CVV doesn't correctly get passed w/o explicit conversion

 

I removed the + 0 and the commented out text and that seemed to do it!

 

Now line 246 reads

 

x_card_code => $_POST['cc_cvv'],

 

 

VERY simple!!!

Life Is Too Short,

Enjoy Your Coffee!

Pete

Link to comment
Share on other sites

I was using the contrib found at

http://www.oscommerce.com/community/contributions,4091

 

and the newest one from weiyin

 

I just checked that profile and they only have one posting.

 

I think I am going to delete it and overwrite it with an earlier version. I don't like the idea of a brand new members contrib.

Life Is Too Short,

Enjoy Your Coffee!

Pete

Link to comment
Share on other sites

I was using the contrib found at

http://www.oscommerce.com/community/contributions,4091

 

and the newest one from weiyin

 

I just checked that profile and they only have one posting.

 

I think I am going to delete it and overwrite it with an earlier version. I don't like the idea of a brand new members contrib.

 

haha, I looked at the last addition, and in fact, the answer to problem was in his new post description:

 

So I added a tiny command to explicitly change it from a string to an integer,

 

duhhh : 072 + 0 = 72

 

there we go!

 

I was surprised not to hear about this issue from clients running with the AIM from VGER (and I have some "pitbull" customers, letting me know very loud when something - even tiny - doesn't work) . I'm glad I didn't install this update!

Link to comment
Share on other sites

After closer looking I think it looks OK. Just my own red flags going up!

 

With such an easy fix is it needed to post it to the contrib file?

 

I think you're right: this mod should be deleted before we do further testing on it. What was the rationale behind changing the string to an integer? Passing the IP seems good however.

Link to comment
Share on other sites

I just did a quick fix and a couple test orders and it worked!

 

On line 246

 

 

 

I removed the + 0 and the commented out text and that seemed to do it!

 

Now line 246 reads

VERY simple!!!

 

Nevermind. Found it (post edited)

Edited by jonw118
Link to comment
Share on other sites

I'm not seeing that line in Checkout_Process... which file did you edit to find that one?

 

You may not have it if you didn't install the latest contrib. In that case, you're safe!

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...