authorize.net problems

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?

scottb:

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/showthread.php?t=52992&highlight=Authorize.net+1.3.6

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?

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

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?

billc108:

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.

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.

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?

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?

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.

billc108:

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?

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

DrByte:

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.

stebbing:

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

Me too, as above.

stebbing:

I will try debugging code also to echo values of $response, $response[0], and $x_response_code at each step along the way.
Sounds good. Let us know if you find anything.

The authorizenet_aim module is written for the 3.1 Transaction Version mode.
I'm not certain whether having one's account in 3.0 mode will cause a problem or not, as we force communications into the newer 3.1 mode and communicate on that basis. Ideally authorizenet's servers should recognize that and process accordingly.

====================

I've attached an updated version of the v1.3.7 module which incorporates the 'echo' debug option mentioned earlier.
To activate it, you'll need to run the following in the SQLPatch tool:

UPDATE configuration set configuration_value = 'echo' where configuration_key = 'MODULE_PAYMENT_AUTHORIZENET_AIM_DEBUGGING';

This will dump the submitted data to the screen (according to what authnet's server sees) and will not complete the transaction.

====================
If you set the debug level to 'All' instead of 'echo' in the above SQL statement, you'll get the debug logging to work even for successful transactions.

A successful transaction should look like this:

Jan-04-2007 04:49:24
=================================

Response Code: 1.  (this is $x_response_code)

Details: Array
(
    [0] => 1    (this is $response_code)
)
 Array
(
    [0] => This transaction has been approved.  (this is $response_text)
)
Sending to Authorizenet:    (this is $reportable_submit_data)
(
    [x_login] => *******
    [x_tran_key] => *******
    [x_relay_response] => FALSE
    [x_delim_data] => TRUE
    [x_version] => 3.1
    [x_type] => AUTH_ONLY
    [x_method] => CC
    [x_amount] => 1.95
    [x_card_num] => *******1324
    [x_exp_date] => 0107
    [x_card_code] => *******
    [x_email_customer] => FALSE
    [x_email_merchant] => FALSE
    [x_cust_id] => 10
    [x_invoice_num] => 88
    [x_first_name] => #########
    [x_last_name] => #########
    [x_company] => 
    [x_address] => 45 #########
    [x_city] => #########
    [x_state] => #########
    [x_zip] => #########
    [x_country] => United States
    [x_phone] => 
    [x_email] => #########
    [x_ship_to_first_name] => #########
    [x_ship_to_last_name] => #########
    [x_ship_to_address] => 45 #########
    [x_ship_to_city] => #########
    [x_ship_to_state] => #########
    [x_ship_to_zip] => #########
    [x_ship_to_country] => United States
    [x_description] => Sample of Product Free Shipping Type (qty: 1) 
    [Date] => January 4, 2007, 4:49 am
    [IP] => #########
    [Session] => 3aa2d9da26a31db682afe2d13d111ad5
    [url] => https://secure.authorize.net/gateway/transact.dll
)


Results Received back from Authorizenet:   (this is $response)
(
    [0] => 1
    [1] => 1
    [2] => 1
    [3] => This transaction has been approved.
    [4] => A43F97
    [5] => P
    [6] => 0
    [7] => 88
    [8] => Sample of Product Free Shipping Type (qty: 1)
    [9] => 1.95
    [10] => CC
    [11] => auth_only
    [12] => 10
    [13] => #########
    [14] => #########
    [15] => 
    [16] => 45 #########
    [17] => #########
    [18] => #########
    [19] => #########
    [20] => United States
    [21] => 
    [22] => 
    [23] => #########
    [24] => #########
    [25] => #########
    [26] => 
    [27] => 45 #########
    [28] => #########
    [29] => #########
    [30] => #########
    [31] => United States
    [32] => 
    [33] => 
    [34] => 
    [35] => 
    [36] => 
    [37] => F6B5AAD927C20AF5CF698D2DF5F57228
    [38] => 
    [39] => 
    [40] => 
    [41] => 
    [42] => 
    [43] => 
    [44] => 
    [45] => 
    [46] => 
    [47] => 
    [48] => 
    [49] => 
    [50] => 
    [51] => 
    [52] => 
    [53] => 
    [54] => 
    [55] => 
    [56] => 
    [57] => 
    [58] => 
    [59] => 
    [60] => 
    [61] => 
    [62] => 
    [63] => 
    [64] => 
    [65] => 
    [66] => 
    [67] => 
    [68] => January 4 2007 4:49 am
    [69] => #########
    [70] => 3aa2d9da26a31db682afe2d13d111ad5
)


CURL communication info:  (this is $commInfo)
(
    [url] => https://secure.authorize.net/gateway/transact.dll
    [content_type] => text/html
    [http_code] => 200
    [header_size] => 283
    [request_size] => 958
    [filetime] => -1
    [ssl_verify_result] => 0
    [redirect_count] => 0
    [total_time] => 0.272523
    [namelookup_time] => 0.001023
    [connect_time] => 0.051496
    [pretransfer_time] => 0.165634
    [size_upload] => 0
    [size_download] => 437
    [speed_download] => 1603
    [speed_upload] => 0
    [download_content_length] => 437
    [upload_content_length] => 0
    [starttransfer_time] => 0.272491
    [redirect_time] => 0
)

[I]If CURL proxy was used, the proxy details will be listed here too.[/I]

NOTE: attached zip removed and replaced by new zip later on in this thread

Cool. Thank you, good doctor.

Those of you debugging may want to change the set_function field in MODULE_PAYMENT_AUTHORIZENET_AIM_DEBUGGING to

zen_cfg_select_option(array('Off', 'Log File', 'Log and Email', 'echo', 'All'),

which will give you an "echo" and "All" choice. Makes it easier to switch debug modes.

I'm not seeing any differences or improvements yet.

I also tried forcing x_version=3.0. No joy there.

It has been almost 10 days and I have tried everything in this post and other posts to get authorize.net to work.

I am totally flustrated and may have to use X-Cart for this store.

Ok. I just talked to Authorize again.

One difference we found between my two stores was that the non-working one is set to return pipe-delimited data (settings>transaction response settings>direct response) where as the other was set to "no". I've tried it both ways, and there's no difference in what I see coming back.

The stuff we're dumping to screen right now is just a reflection of what we're sending. We know that's good, as Authorize is accepting the charge - they just can't talk back to the ZenCart to tell it.

With a little juggling around of the code (leave it on 'echo' but comment out line 371 so it posts to the live gateway instead of the parameter dump refector) I now get back:

1|1|1|This transaction has been approved.|008333|Y|1303863459|9|test product (qty: 1)|0.01|CC|auth_capture|3|

etc....

which appers to be the raw data stream they send back. It certainly matches what I've seen when dealing with them previously, hand-coding gateways in another language.

So it appears by the third entry there being a "1" and the fourth clearly stating that it's been approved that Auth.net is doing what they should. Correct me if I'm wrong.

I'm going to hack around on this some more and see if I can make it work, just wanted to let y'all know what I've found so far.

This is the error I get no matter what I do.

It returns to screen two of the checkout process.

billc108 ...

Change the delimiter to commas ... any change?