authorize.net problems

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

[DrByte]

What files aside from includes/modules/payment/authorizenet_aim.php are involved in accepting Authorize.net AIM payments?

Other than the related language file of the same name, that's it.

If the ID+key from the other a-net account worked fine, then I'm inclined to blame the account. What did authnet staff say about the 3.0 vs 3.1 ?
As an aside, I assume you've regenerated a new transaction key as part of your troubleshooting?

[stebbing]

Hi all,

I have been following this thread with considerable interest as I have the same issue. I am getting the same values back from authnet but the message and redirect say the same: "This transaction has been approved - Your credit card could not be authorized...."

authnet is approving and sending back "1,1,1,This transaction has been approved.."
but when we use code to check value of $x_response_code, which should have same value as $response_code[0] it returns other than
1.


I forced $x_response_code to 1 and got the success page...

Somewhere between stuffing the values into the $response array and the if statement below I am changing values....

if ($x_response_code != '1') {
$messageStack->add_session('checkout_payment', $x_response_text . ' - ' . MODULE_PAYMENT_AUTHORIZENET_AIM_TEXT_DECLINED_MESSAGE, 'error');
zen_redirect(zen_href_link(FILENAME_CHECKOUT_PAYMENT, '', 'SSL', true, false));

I am using 1.3.5, with the latest 1.3.7 authorizenet_aim.php file. Changed keys etc. and same error. My data base is getting the value of 0 for the response code, even though approved and sent 1 from authnet.

I will try debugging code also to echo values of $response, $response[0], and $x_response_code at each step along the way.

Scott

[billc108]

If the ID+key from the other a-net account worked fine, then I'm inclined to blame the account. What did authnet staff say about the 3.0 vs 3.1 ?
As an aside, I assume you've regenerated a new transaction key as part of your troubleshooting?

Auth said they didn't think any of the 3.0 v 3.1 changes would affect this. I'm going to press them more on it tomorrow.

Yes, I did get a new transaction key.

I suspect it's them, just want to make sure - and know how to identify the likely cause.