Authorize.net SIM Errors - 1.3.9f & g

[indy1725]

just upgraded to version 1.3.9g today, to try to resolve an issue that came up when I upgraded to 1.3.9f:

I'm trying to use the Authorize.net SIM module to process credit card payments, but it fails when it tries to send information back to the store. I've tried uninstalling the module and reinstalling it, I've generated new Transaction Keys, and verified that my Hash code matches on both sites.

But still, every test order I try to put through fails when I try to submit it.

I'm collecting the info on Authorize.net, and the order info and shipping info all makes it over there just fine, but when I confirm the order at authorize.net, I am bounced back to my own site with the following message:

"An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

This transaction has been approved.

It is advisable for you to contact the merchant to verify that you will receive the product or service."

The automated Authorize.net SIM alerts don't say anything about a failure, except sometimes I get a second follow-up email stating there has been a [HashMatchStatus] => FAIL.

When i click on the transact.dll link in the Alert emails, I'm shown this message:

"The following errors have occurred.
(13) The merchant login ID or password is invalid or the account is inactive."

However I have no problem logging in to the Authorize.net merchant account, and the login ID and password all match (yes, I did check for miscapitalization).

Before I noticed this error and disabled the module, orders were still going through to Authorize.net, and my customers' cards were being charged. The orders were never confirmed with my store, however, so no new orders were being generated.

I'd hoped that the advertised Authorize.net fixes in 1.3.9g would solve my problem, but they didn't. I'm not sure when the bug was introduced, I noticed in in 1.3.9f, but I think I upgraded from c or d at the time.

Any suggestions would be appreciated, though i've already tried all of the ideas that people have been posting with similar problems. I can't switch to AIM at the moment, it's just an option I can't afford right now.

[DrByte]

- I'm unclear about why you're blaming v1.3.9f/g specifically. The changes to the module since v1.3.8 are minimal.

- The "An error occurred while trying to report this transaction to the merchant...." message occurs when Authnet tries to send the customer back to your site but it doesn't respond normally. This is usually a problem caused by badly written so-called SEO mods that rewrite URLs, or by hosting on a server that's suddenly too slow to respond.

- Are there any debug logs in the /cache/ folder? Maybe it's reporting PHP errors there that might be causing the customer (and therefore authnet) to encounter a blank page upon return? Those are common when upgrading a site and making small typos in language files etc.

[indy1725]

Howdy, DrByte:

You're right, apparently I was upgrading from 1.3.8a, not a later version. I'm not sure what changed between them, but I know this problem didn't occur before I upgraded.

I checked my debug logs in /cache/, and here is what I found:

Oct-12-2010 07:58:54
=================================

Sent to Authorizenet: Array
(
[x_login] => *******
[x_amount] => 36.50
[x_version] => 3.1
[x_method] => CC
[x_type] => AUTH_CAPTURE
[x_cust_ID] => 33
[x_email_customer] => TRUE
[x_company] => Home
[x_first_name] => ******
[x_last_name] => ******
[x_address] => ******.
[x_city] => ******
[x_state] => ******
[x_zip] => ******
[x_country] => United States
[x_phone] => ******
[x_fax] =>
[x_email] => ******
[x_ship_to_company] => Home
[x_ship_to_first_name] => ******
[x_ship_to_last_name] => ******
[x_ship_to_address] => ******.
[x_ship_to_city] => ******
[x_ship_to_state] => ******
[x_ship_to_zip] => ******
[x_ship_to_country] => United States
[x_Customer_IP] => ******
[x_relay_response] => TRUE
[x_relay_URL] => ******/index.php?main_page=checkout_process&action=confirm
[x_invoice_num] =>
[x_duplicate_window] => 120
[x_allow_partial_Auth] => FALSE
[x_description] => Website Purchase from Lunarbistro.com
[x_fp_sequence] => 873
[x_fp_timestamp] => 1286938734
[x_fp_hash] => 35646837cc2b7e91d4336ded523ed830
[x_show_form] => PAYMENT_FORM
[x_receipt_link_method] => POST
[x_receipt_link_text] => Click here to complete your order.
[x_receipt_link_url] => ******/index.php?main_page=checkout_process
[x_Test_Request] => TRUE
[zenid] => 8jbhontrcfdqo5gje21qv2ri87
[url] => https://secure.authorize.net/gateway/transact.dll
)

Any ideas? I'll poke through the code and see what I can figure out.

[DrByte]

Okay, so in the /cache/ folder you found Authnet transaction logs. That's fine ... so it appeasr to be properly preparing the content to send TO authorize.net.

I was asking whether you have any *debug* logs. More specifically, myDebug-xxxxxxxxxxxxx.log files. ref: https://www.zen-cart.com/tutorials/index.php?article=82

[indy1725]

I was getting MyDebug files, but they were due to an outdated install of BetterTogether. I've updated that to the latest version, and now there are no new MyDebug files being generated when I submit an order. However, the orders are still failing to submit properly from Authorize.net.

[indy1725]

One other thing I noticed in doing all this testing, it appears that with the recent versions (after my upgrade from 1.3.8a) of the SIM Module, the CVV field no longer shows up on the Authorize.net page, whether I request that info or not. I don't know how or if that's related to this problem, but I noticed it.

[DrByte]

The fields shown on the Authorize.net page while your customer is *there*, are controlled by whatever settings you've set up for form fields within your Authorize.net account in your merchant settings area. Contact your Authorize.net rep for help with controlling those.

[DrByte]

What addons do you have installed?
What redirects have you built for your site?

[indy1725]

I don't have any redirects on the store part of my site...

The add-ons i have installed are:
Add Customers From Admin 1.02
Better Together 2.3a
Inventory Report
Sales Report Graphs 1.02
Simple Create Orders
Stock By Attribute
and the USPS shipping module update from January 4, 2010.

Most of those are Admin addons, and I wouldn't have expected them to affect the customer side of the store, or have any interaction with the order/payment modules.

[DrByte]

I checked my debug logs in /cache/, and here is what I found:

Oct-12-2010 07:58:54
=================================

Sent to Authorizenet: Array
(
[x_login] => *******
[x_amount] => 36.50
[x_version] => 3.1
[x_method] => CC
[x_type] => AUTH_CAPTURE
[x_cust_ID] => 33
[x_email_customer] => TRUE
[x_company] => Home
[x_first_name] => ******
[x_last_name] => ******
[x_address] => ******.
[x_city] => ******
[x_state] => ******
[x_zip] => ******
[x_country] => United States
[x_phone] => ******
[x_fax] =>
[x_email] => ******
[x_ship_to_company] => Home
[x_ship_to_first_name] => ******
[x_ship_to_last_name] => ******
[x_ship_to_address] => ******.
[x_ship_to_city] => ******
[x_ship_to_state] => ******
[x_ship_to_zip] => ******
[x_ship_to_country] => United States
[x_Customer_IP] => ******
[x_relay_response] => TRUE
[x_relay_URL] => ******/index.php?main_page=checkout_process&action=confirm
[x_invoice_num] =>
[x_duplicate_window] => 120
[x_allow_partial_Auth] => FALSE
[x_description] => Website Purchase from Lunarbistro.com
[x_fp_sequence] => 873
[x_fp_timestamp] => 1286938734
[x_fp_hash] => 35646837cc2b7e91d4336ded523ed830
[x_show_form] => PAYMENT_FORM
[x_receipt_link_method] => POST
[x_receipt_link_text] => Click here to complete your order.
[x_receipt_link_url] => ******/index.php?main_page=checkout_process
[x_Test_Request] => TRUE
[zenid] => 8jbhontrcfdqo5gje21qv2ri87
[url] => https://secure.authorize.net/gateway/transact.dll
)

That's exactly the same thing I get when I do transactions, and they work just fine. So, that confirms that your problem is not with the main Zen Cart code, and reaffirms to me that your problem is something wrong with something in how you've configured your site. ie: things like:
- rewrite rules not written properly
- htaccess settings causing conflicts
- slow server
- improperly configure SSL certificate
- broken addons
- etc