authorize.net problems

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

[billc108]

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

Me too, as above.

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.

[DrByte]

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
)

If CURL proxy was used, the proxy details will be listed here too.

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

[billc108]

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.

[scottb]

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.

[billc108]

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.

[scottb]

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

It returns to screen two of the checkout process.

[Ajeh]

billc108 ...

Change the delimiter to commas ... any change?