Authorize.net SIM Errors - 1.3.9f & g

[indy1725]

To address these issues:

- rewrite rules not written properly
-- As I said, I'm not using any rewrite rules on my site, unless there are some in zencart of which I'm not aware.

- htaccess settings causing conflicts
-- The only htaccess that I have are the ones that came with zencart

- slow server
-- I'm not sure how to check this, but the error message is popping up almost immediately, certainly before the 10 second limit for a slow-server error.

- improperly configure SSL certificate
-- I don't have an SSL certificate, otherwise I'd switch over to using the AIM module instead of the SIM module

- broken addons
-- I've double-checked to make sure I'm running the most recent versions of all of my addons. I suppose it's possible that one of them might still be faulty, but would admin-side addons really be able to effect the customer experience? I thought all these did was to provide me different ways to manage the data that's presented.

ACTUALLY, my mistake - looks like there HAS been a newer release of Stock By Attributes for 1.3.9+. I'll update that and see if it helps at all.

[indy1725]

error post.

[indy1725]

Okay, back again, and with no good news.

I updated my Stock By Attributes module, and it did not solve the problem. I'm still getting SIM errors when Auth.net tries to send the order back to my site.

I even found the thread from last June (http://www.zen-cart.com/forum/showth...=158496&page=7) talking about Authorize.net's change in the x_amount field to 4 decimal places and applied that fix in my authorizenet.php file and it didn't help.

The hashmatchstatus = FAIL is only generated when I actually follow through to the x_relay_URL manually - my browser gets hung up on the first error so it never makes it to that page.

I don't know, I'm out of ideas and tired of trying to figure this out. Anyone else have any suggestions? I've been paying for this merchant account for months now and not been able to use it because of this bug, whatever it is.

[DrByte]

I'm not clear what the present problem is anymore. What exactly does "I'm still getting SIM errors" mean? What exact "errors"?
And why is nobody else having this problem?

[indy1725]

I'm not clear what the present problem is anymore. What exactly does "I'm still getting SIM errors" mean? What exact "errors"?
And why is nobody else having this problem?

As I've said, I'm having a very difficult time pinpointing the error I'm getting. When I place an order through my site, using the Authorize_SIM module, I get sent to the page at Authorize.net. Using the test-Mastercard number provided by the module, I click Submit, and am brought to a page which reads only:

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

Checking in the cache folder, I find the new SIM_debug log, which reads thus:

"Nov-07-2010 08:53:30
=================================

Sent to Authorizenet: Array
(
[x_login] => *******
[x_amount] => 23.57
[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] => 24.20.44.193
[x_relay_response] => TRUE
[x_relay_URL] => ********/store-zen/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] => 22
[x_fp_timestamp] => 1289192010
[x_fp_hash] => 4c70e828cca7cfd88a8678b261c89167
[x_show_form] => PAYMENT_FORM
[x_receipt_link_method] => POST
[x_receipt_link_text] => Click here to complete your order.
[x_receipt_link_url] => ********/store-zen/index.php?main_page=checkout_process
[x_Test_Request] => TRUE
[zenid] => jv7ouf4pbkh64n5g8bj32c5i47
[url] => https://secure.authorize.net/gateway/transact.dll
)


"

No order is generated at my store, however the receipt is emailed to me.

When I go to the 'x_relay_URL' in the SIM-debug report, I see the shopping cart page of my site, with the error message: "There has been an error processing your credit card. Please try again."

When I go to the 'x_receipt_link_url' in the SIM-debug report, I see the same.

When I go to the 'url' at the bottom of the SIM-debug report, I see a page which says only:
"The following errors have occurred.
(13) The merchant login ID or password is invalid or the account is inactive."

After viewing that page, a second SIM-debug file is generated, with this content:

"Nov-07-2010 08:59:30
=================================

Response Code: .
Response Text:

Results Received back from Authorizenet: Array
(
[HashValidationValue] => B9A2099503DACCA8B568E23D852986E0
[HashMatchStatus] => FAIL
[url] => https://secure.authorize.net/gateway/transact.dll
)
"

This is the closest I can get to actually seeing what's happening here, and it looks like the whole thing is being triggered by a hashMatchStatus failure.

And I have no idea why nobody else is having the same problem. I don't believe that my site is configured in such an unconventional way, the php code is entirely untouched to my knowledge, except where it's drawing the html. And as I stated before, this all worked perfectly fine under my previous version, which was 1.3.8.

[DrByte]

The transaction flow is this:

First, you add something to your cart, and go through checkout. At the final Confirmation page on *your* site, you click the Confirm button, and you are redirected to the Authorize.net site.

Before sending you over to the Authorize.net site, this log file is generated, simply to record the details being *submitted* for the transaction. Hence the notation "Sent to Authorize.net:".

Checking in the cache folder, I find the new SIM_debug log, which reads thus:

"Nov-07-2010 08:53:30
=================================

Sent to Authorizenet: Array
(
[x_login] => *******
[x_amount] => 23.57
[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] => 24.20.44.193
[x_relay_response] => TRUE
[x_relay_URL] => ********/store-zen/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] => 22
[x_fp_timestamp] => 1289192010
[x_fp_hash] => 4c70e828cca7cfd88a8678b261c89167
[x_show_form] => PAYMENT_FORM
[x_receipt_link_method] => POST
[x_receipt_link_text] => Click here to complete your order.
[x_receipt_link_url] => ********/store-zen/index.php?main_page=checkout_process
[x_Test_Request] => TRUE
[zenid] => jv7ouf4pbkh64n5g8bj32c5i47
[url] => https://secure.authorize.net/gateway/transact.dll
)

Then ...

Using the test-Mastercard number provided by the module, I click Submit, and am brought to a page which reads only:

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

Normally if there are no communications problems with Authorize.net reaching your store to tell it of the completed payment (which happens by virtue of the URL you mentioned in the log file, and below), then you will be taken to the checkout_success screen of your site, after a moment of processing the returned response received by your store.

Instead, you're receiving a message which indicates that Authorize.net couldn't confirm that your store would acknowledge their payment notice. Thus they display the error message.
This problem is explained on the Authorize.net website and also in our FAQs here: https://www.zen-cart.com/tutorials/index.php?article=402

No order is generated at my store, however the receipt is emailed to me.

Naturally. Your store never received confirmation of the payment. Thus it has no order to generate.

However, since Authorize.net already accepted and authorized the payment before that earlier problem occurred, they still send out their own payment notice message as they normally do.

When I go to the 'x_relay_URL' in the SIM-debug report, I see the shopping cart page of my site, with the error message: "There has been an error processing your credit card. Please try again."

When I go to the 'x_receipt_link_url' in the SIM-debug report, I see the same.

To be expected. The link only "works" if there is also returned data coming along with the visit to that link, which of course you don't have when using your browser to test it.

When I go to the 'url' at the bottom of the SIM-debug report, I see a page which says only:
"The following errors have occurred.
(13) The merchant login ID or password is invalid or the account is inactive."

That's to be expected, since you're only visiting their entry-point URL which can only process something if valid transaction data is being passed, which you're not doing when you're just putting that URL in your browser.

After viewing that page, a second SIM-debug file is generated, with this content:

"Nov-07-2010 08:59:30
=================================

Response Code: .
Response Text:

Results Received back from Authorizenet: Array
(
[HashValidationValue] => B9A2099503DACCA8B568E23D852986E0
[HashMatchStatus] => FAIL
[url] => https://secure.authorize.net/gateway/transact.dll
)
"

In this case you're getting no usable data. The HashValidationValue is calculated from the returned data (which is blank), and thus the HashMatchStatus will certainly be FAIL because there's nothing to compare it to.

it looks like the whole thing is being triggered by a hashMatchStatus failure.

No. As I said above, that's a symptom caused by the lack of data received.



In short, your problem is that your site is not responding correctly when Authorize.net redirects the customer back to your store.
As per the FAQ, that can be caused by many kinds of things, including but not limited to bad .htaccess redirect rules, so-called SEO mods breaking proper functionality, bad return URLs, very slow webserver, broken sessions/cookies, and the list goes on.

[indy1725]

I really appreciate your taking the time to continue helping me try to identify the problem here. Unfortunately the causes you list, "including but not limited to bad .htaccess redirect rules, so-called SEO mods breaking proper functionality, bad return URLs, very slow webserver, broken sessions/cookies", have already been eliminated as possible causes, as I mentioned in an earlier reply.

You offhandedly state, "and the list goes on," any suggestions what else might be causing this error?

I've been assured by Dreamhost that they're not blocking these transactions, and the error message is popping up before the 10-second limit. I'm successfully using sessions and cookies elsewhere on my site, so I think that can't be the problem.

My next step is to reinstall the version of Zencart which was last working for me, 1.3.8a, and see if the orders go through successfully.

[indy1725]

Problem FIXED!

I installed a basic 1.3.8a storefront on another domain I host with the same company, created a sample order, and it went through just fine using all the same settings as my 1.3.9g storefront. Credit card info was sent and confirmed, an order was generated, perfect!

It occurred to me that one of the differences between them (aside from the code base) was that I hadn't bothered to turn on Maintenance Mode to test the payment module in the 1.3.8 install. I went back to my 1.3.9g install, turned off Maintenance Mode, made sure the Authorizenet SIM was still in test mode so I wouldn't get charged anything, and the order went through just fine with no problems!

So, the cause of the initial bug when this was originally brought to my attention, I don't know. It was probably wiped out when I upgraded to 1.3.9. HOWEVER, as I was continuing to test the SIM module while my store was in Maintenance Mode, this continued to cause the failure to communicate.

Simply put: If you're trying to test the Authorize.net SIM Payment Module, make sure your store is NOT in Maintenance Mode - the order will FAIL!

[DrByte]

Right. General rule of thumb: Maintenance mode is NOT suitable for production activities, including taking payments.