authorize.net problems

scottb ...

You have tried the following:

1 Made a transaction on AuthorizeNet's site to make sure the account is working

2 Removed and Installed Authorize Net AIM (make sure other payment modules are not installed and just disabled)

3 Regenerated your: Transaction Key

4 Cut and Paste from email your API Login ID and your Transaction Key

5 Checked that ports 80 and 443 are open both directions

Progress!

It appears that what's missing is that there's another array in there. When I use this (starting at about line 401):

$response = split(',', $authorize);

//echo "first response = "; print_r($response);

$exploded_response = explode('|', $response[0]);

echo "<br>exploded_response = "; print_r($exploded_response);
echo "<br><br>";

$response_code= explode (',', $exploded_response[2]);

echo "<br>response_code = "; print_r($response_code);
echo "<br><br>";

$response_text = explode(',', $exploded_response[3]);


$transaction_id = explode(',', $exploded_response[6]);
$authorization_type = explode(',', $exploded_response[11]);
$auth_code = explode(',', $exploded_response[4]);
$this->auth_code = $auth_code[0];
$this->transaction_id = $transaction_id[0];
// Parse the response code and text for custom error display
$x_response_code = $response_code[0];
$x_response_text = $response_text[0] . ($commError == '' ? '' : 'Communications Error - Please notify webmaster. ');

Along with some other hacks. The account now shows that the payment/order went through! woo hoo!

The Authorize guy I spoke with this morning said that they'll reflect whatever delimiter Zen sends them, overriding what is in their settings. Does Zen send a delimiter? I get pipes back even when the default there is set to "no". (hmmmm... )

Ajeh, you called it. Setting it to comma delimited works with the original file. Any way we can have that set to something else - like pipe, which the existing gateway on this store requires? Set another parameter in the Authorizenet_aim.php file that can be set by the Admin?

(ps: sorry for the delay on the promised xmas gift to the Zen team. It's still coming...)

I was thinking along the same lines last night ... which is why the module I posted last night forces delimiter to be comma, overriding whatever your authorizenet account settings are set to.

Here's the deal as far as i can tell: Even though I had set the delimiter to "no" on Authorize.net's settings, it still responded with the previously listed and can't-get-rid-of-it pipe.

So despite the fact that Auth.net claims that what you send as delimiter will override the settings on their site, it doesn't actually do that.

When I insert the following delimiter declaration at about line 317
of the original 1.3.7 authorizenet_aim.php file to

'x_delim_char' => '|', // The default delimiter is a comma

(which wasn't set at all in the 1.3.7 file)
and line 415 or so to:

$response = split(',', $authorize);

$response_code = explode('|', $response[0]);
$response_text = explode('|', $response[3]);
$transaction_id = explode('|', $response[6]);
$authorization_type = explode('|', $response[11]);
$auth_code = explode('|', $response[4]);

it works when I have it set for pipe on the Auth.net side. Interestingly, it appears to work when I set it to pipe over there too. Hmmm again.

Anyway, mine's working now, so I can move on to all the other stuff I still need to do to get this site live by, oh, four days ago.

Updated module attached, which sets the delimiter and parses accordingly.
Parser is more intelligent now too and can handle encap characters also.
In fact, the module now explicitly sets the delimiter to | and encap to * so that it knows what to expect back from authorizenet.
Using the | is likely safer than using the comma because one could use a comma in their address and end up with a problem ... whereas a | is highly unlikely, and stripping out | symbols is likely less confusing than stripping commas. (Keep in mind that the ZC AIM module has always been stripping commas before sending, so as to prevent against these problems).

Very nice, thanks.

I used pipe on the previous gateway for that exact reason - some of the fields had commas in the data, and pipe makes much more sense in that way.

Hope this helps the others who were having Authorize AIM problems as well.

Ajeh,

1. The transactions go through at authorize.net and my credit card is charged

2. Removed and reinstalled the module a couple of times

3. Regenerated transaction key twice

4. Did cut and paste

5. The ports are open

Make sure that you do not have Installed and set to off any other payment modules ...

Only have installed Payment modules that you are using ... example AuthoriseNet SIM make sure that is not installed ...

Try changing the delimiter on AutorizeNet site to the Pipe | and try the AuthorizeNet update DrByte has posted above ...

Again, I would unstall the existing AuthorizeNet AIM ... load the new module from DrByte ... Install and configure via cut and paste ...

Make sure you AuthorizeNet is set to Live or Production ... Make sure your Zen Cart settings are for Live as well ...

Dr. Bytes's new script works great except now I am getting a run time error.

Could you post the error so we can see it? :smile:

Here are the runtime errors I get in step two of the checkout.

What happens if you turn off your debugging in your browser?

The transactions go through fine with debugging turned off. I always run my production computers with several debugging tools active.

Now how do I get rid of this from step 2 of the check-out process?

MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK

See above error jpgs

MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK
That is a constant, defined in the language file:
/includes/languages/english/modules/payment/authorizenet_aim.php

  define('MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK', 'What\'s this?');

I believe that entry was added for v1.3.7 ... which is likely why you're not seeing it, since in your case you started using this code to fix a problem -- before 1.3.7 was even released.

That define line does not exist in my /includes/languages/english/modules/payment/authorizenet_aim.php file

I am using 1.3.6

It does exist here

/includes/modules/payment/authorizenet_aim.php

Line #175 : 'field' => zen_draw_input_field('authorizenet_aim_cc_cvv', '', 'size="4", maxlength="4"' . ' id="'.$this->code.'-cc-cvv"' . $onFocus) . ' ' . '<a href="javascript:popupWindow(\'' . zen_href_link(FILENAME_POPUP_CVV_HELP) . '\')">' . MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_POPUP_CVV_LINK . '</a>',

But it breaks the checkout if I touch the line.

billc108:

Scott B, you wouldn't happen to be running on Mac OS 1.3.9 would you?

Is this a problem if you are using OS 1.3.9? It would help explain our problems with AIM!:)

DrByte:

Updated module attached, which sets the delimiter and parses accordingly.
Parser is more intelligent now too and can handle encap characters also.
In fact, the module now explicitly sets the delimiter to | and encap to * so that it knows what to expect back from authorizenet.
Using the | is likely safer than using the comma because one could use a comma in their address and end up with a problem ... whereas a | is highly unlikely, and stripping out | symbols is likely less confusing than stripping commas. (Keep in mind that the ZC AIM module has always been stripping commas before sending, so as to prevent against these problems).

Thank you Drbyte for this fix. We installed it last month when it was discovered that single quotes returned from authorize.net in the city feild caused errors. Since the install, orders come through fine...I thought everthing was good until we started getting calls from customers not able to use their Amex card. After looking into the issue, we discovered that we haven't had any amex transactions since installing this upgrade. I have done some homework to pinpoint the problem, and here is what I found out:

• We have processed many amex cards before this update
• I can still process Amex through the virtual terminal on Auth.net
• My processesor has confirmed that everything is still set up correctly
• I also compared my installed file with the one in your zip file, and it is an exact match.
• To clarify, it's: @version $Id: authorizenet_aim.php 5534 2007-01-05 10:21:51Z drbyte $
• The error that I receive after entering an amex number is: The credit card number starting with xxxx was not entered correctly, or we do not accept that kind of card. Please try again or use another credit card.
  Visa & MC work perfectly, just Amex is the issue.

FYI, AIM is the only payment module I have enabled.

I looked through the code and compared the changes with the original...unfortunately I am not very good with php (pretty new to zc too) and nothing jumped out at me as a source for the problem.

Do you have any suggestions? Any help is much appreciated, I need to get this running smoothly again...

FYI, I'll be adding Discover after Amex is back up and running, and finally, I plan to add Paypal as an alternative method of payment (but not until AIM is solid).

Thanks!!

1. Do you have Amex enabled in Admin->Configuration->Credit Cards ?

2. The 'we don't accept that kind of card' message is a result of the card number-validation failing. Credit Card number-validations happen via /includes/classes/cc_validation.php. Amex rules are defined there along with all the other card types. Have you changed that file at all ? The one that comes with v.1.3.7 / v1.3.7.1 is the most current.

The rule is: ereg('^3[47][0-9]{13}$', $number) ... which means: starts with 34 or 37 and has 13 more digits.
What pattern is the amex number you were trying?

Well...that's why you're the doctor!

Somehow Amex was turned off from admin. I had someone helping me, they must have done that when they installed the upgrade...probably for testing & forgot to turn back on. Anyway, I just put an order through, so its golden.

One question though...Amex (at least mine) has 15 digits, not 13...I guess the reg exp checks for the first 2 digits and counts the rest?

No biggie, because my site is working right now - just the curiousity factor.

Thanks again DrByte!