authorize.net problems

[scottb]

I am on a Linux server.

CentOS
Apache/1.3.37 (Unix)
PHP/4.4.4
MySQL 4.1.21

I have been on the phone with authorize.net and have done transactions where the authorize.net person can see the transaction in real time. Everything works fine on their end.

I posted in an earlier post in this thread the return I get from authorize.net.

Is it a problem with version 1.3.6?

[SPH]

Is it a problem with version 1.3.6?

No, 1.3.6 is okay. (Assuming you've installed correctly.)

Had similar problem not too long ago. Multiple phone calls to Authorize.net finally revealed it was a problem at their end.

Here's my thread on that:

http://www.zen-cart.com/forum/showth...rize.net+1.3.6

[billc108]

Does Zencart send a response URL? Would it help speed things along if I entered one in the authorize.net settings? If so, what should it be?

[DrByte]

No, Zen Cart does no secondary response. It does direct communication and does not need a response URL.

[billc108]

Any other suggestions of where to look then? I've compared the AuthNet settings that I can get to between the working and non-working stores, and the only difference I can see is that the working one shows the Transaction Version as

Current Version:3
Transaction Version [3.1] <<-- this is a dropdown, with "3.1" the only choice

(suggesting to me that Zen is programmed for v3.0) and the non-working store just shows:

Current Version:3.1

The store which is not working with ZenCart is currently using a different gateway on another server, and that one is using v3.1). It will be redirected to the Zen store once we goes live, but until then I don't think I can revert to 3.0

Looking at the array sent to Authorize, I see [x_version] => 3.1. Did Zen 1.3.5 use [x_version] => 3.0 ? Could that be what's tripping me up?

[DrByte]

Looking at the array sent to Authorize, I see [x_version] => 3.1. Did Zen 1.3.5 use [x_version] => 3.0 ? Could that be what's tripping me up?

There have been no major functional changes to the authorizenet_aim module in the last several releases.

Obtaining the ID and transaction key for the working store to test a couple transactions on the non-working store would be the most revealing test at this point.

[billc108]

Transaction goes through fine using the other store's ID and key. Good call once again, DrByte!

I'll let you know what I find out when I call Authorize.

[billc108]

Authorize said:

"The echo URL is https://developer.authorize.net/param_dump.asp. Insert the URL in place of https://secure.authorize.net/gateway/transact.dll. When the form is submitted it will list all of the name/value pairs that are being sent to us. You should be able to determine where the scripting error is from the results.
"

Did that, but still getting the same response from Zen. ("Your credit card could not be authorized for this reason." etc...).

I'm not sure what to add to the page in order to get the parameter dump show up on screen. Any suggestions?

[billc108]

Ok, there's definitely something not right here. (maybe me...)

I inserted the following lines in the authorizenet_aim.php file at about line 429, as I wasn't getting a screen readout otherwise:

// DEBUG LOGGING
echo 'x_response_code from Auth.net = '; echo $x_response_code; echo ' = end x response code<br />';

$x_response_code=1;

When I run a purchase through with that, I get

x_response_code from Auth.net = REMOTE_ADDR: 205.238.129.202
REQUEST_METHOD: POST
HTTP_REFERER: none

Field Name Field Value
x_login xxxxxxxxxx
x_delim_data TRUE
x_card_code xxxxxxx
x_tran_key xxxxxxxxx
x_first_name NAME
IP 205.238.129.205
Session xxxxxxxxxxx
x_relay_response FALSE
x_phone PHONE
x_version 3.1
x_amount 0.01
x_exp_date xxxx
x_last_name Christensen
x_state Texas
x_email EMAIL
x_type AUTH_CAPTURE
x_company
x_method CC
x_card_num XXXXXXXXXX
x_ship_to_first_name Bill
x_ship_to_last_name Christensen
x_ship_to_address STREET
x_ship_to_city CITY
x_ship_to_state Texas
x_ship_to_zip ZIP
x_ship_to_country United States
x_email_customer FALSE
x_email_merchant FALSE
x_cust_id 3
x_address STREET
x_zip ZIP
Date January 3 2007 3:46 pm
x_test_request TRUE
x_invoice_num TEST-5
x_country United States
x_description test product(qty: 1)
x_city austin
= end x response code

(personal data obscured)

If I'm reading that response, x_response_code equals ALL that data - not a simple 1 or 0. Is that correct behavior?

[billc108]

I've gone over this as many ways as I can think of and see no appreciable difference between the response when using one Auth.net account or the other. And yet one works and the other doesn't. Authorize said that the two accounts looked the same on their end. I'll be calling them back to check it again tomorrow (just missed their end of business by 6 minutes when I tried to call tonight). Any additional checks I can do on this end to eliminate Zen as a possible part of the problem would be good to do.

I've held everything constant except the order number and whether it's in test or production mode, and for all intents and purposes the response I'm seeing appears exactly the same. I assume that I'm looking at the correct data.

I've also tried with a different credit card (ax and visa) just in case. Both are accepted payment methods for both Auth and Zen accounts. Same results.

What files aside from includes/modules/payment/authorizenet_aim.php are involved in accepting Authorize.net AIM payments? Perhaps I missed something when I updated.

Any other suggestions/feedback/code debug snippets appreciated.