Auth.net SIM script timed out while trying to POST transaction results

[RixStix]

Your script timed out while we were trying to post transaction results to it.

I sure could use some help correcting this problem
Tnx
Rick
=================================================
SIM is functional in our sandbox and not functional on our live server. I've compared ZC admin settings in both. The only differences that I can find right now are in the server OS, php version and MySQL version and SSL. Both servers use same ZC versions and same plugins.

Sandbox server: Functional
Production server: Error Script timeout when "Pay Now" button on the Auth.net SIM Form is clicked
Auth.net approves the transaction but nothing happens on the zencart side other than SIM_Debug

ZenCart 1.5.3 both servers. Plugins identical both servers
authorizenet.php files identical on the 2 servers
ZenCart SIM settings identical on the 2 servers
Production VPS server SSL and enabled
Sandbox shared server No SSL

Both servers use the same Auth.net account credentials

Script causing error (I think)

[x_relay_url] => https://chainweavers.com/index.php?main_page=checkout_process&action=confirm

Sandbox server
php 5.3.28
MySQL 5.5.40-cll
Server OS Linux 2.6.32-531.17.1.lve1.2.57.el6.x86_64

Production server
php 5.4.31
MySQL 5.5.39-cll
Server OS Linux 2.6.18-274.7.1.el5

Link suggested earlier by DrByte
http://www.zen-cart.com/content.php?...error-occurred
There are several reasons for seeing this message:

OK 1. Your site is too slow in responding to Authorize.net's attempt to return the customer to your site and/or send back transaction authorization to your site. Maximum 10 seconds is permitted. If your server is slower than 10 seconds when attempting to load a page, you have a more serious problem than merely handling payments. You need to resolve your server speed problem first. Start by talking to your hosting company, and/or consulting our FAQs on speed and performance.

OK 2. If your store is in Down For Maintenance mode, you cannot test SIM transactions.

OK 3. You have the Authorize.net server's IP address blocked in your store's server firewall or .htaccess rules. Consult your server's apache errorlog to find the IP address which is being repeatedly denied when payments are attempted, and unblock it.

BLANK 4. You may have entered invalid URLs into your Authorize.net "Relay Response URL" and/or "Receipt URL" settings. Ideally you should leave them blank and let your store send the proper values with your transactions, or if you are uncomfortable with that for some reason, set them to point to your index.php?main_page=checkout_process URL.

No Known or observed problems 5. You might have a problem caused by an invalid or improperly configured SSL certificate on your site. Thus, if Authorize.net is attempting to respond to your site and your site has problems in SSL mode, then Authorize.net will be encountering either an error message or delayed response, thus triggering symptoms similar to #1 above.

Don't use rewrite rules 6. You might have invalid rewrite rules set as a result of creating or adding an .htaccess file to rewrite URLs as part of so-called "seo" addons, or installed such an addon. Many times such addons fail to properly handle all returning responses from external systems properly, resulting in serious system problems.

Configuration: Sessions: Identical both sites 7. If your site has a problem with sessions handling or cannot properly set a valid session cookie, you might have similar problems because the return response cannot be connected to the customer's original shopping session, and thus an error is returned, and thus Authorize.net doesn't see the expected "200" response code they want to see. (If they don't see a "200" response, they send the error message which is the topic of this article.)

[RixStix]

When I said the authorizenet.php files were identical, I did not specify that the currency_code edits listed in this thread have been made on both servers.

[RixStix]

Disabled SSL by changing all the https to http in both configure.php files. Changed all the SSL=true to false in both configure.php

Same result. Auth.net SIM approving the transaction but nothing happening within ZC. So the SSL in the live site vs no SSL in the test site doesn't appear to be the cause.

Server log for the only auth.net SIM response, but nothing happens within ZC

198.241.168.60 - - [13/Nov/2014:11:00:43 -0800] "POST /index.php?main_page=checkout_process&action=confirm HTTP/1.1" 302 208 "-" "-"

Looking @ server info differences between the two servers shows a few differences. The most significant (to me) is the test site has an entire section labeled SUHOSIN where the live server has nothing.

[DrByte]

Configuration: Sessions: Identical both sites

Are you referring to Zen Cart (Admin->Configuration->Sessions) settings, or PHP (php.ini) settings?
If it's a sessions problem then it's most likely in php.ini

[RixStix]

Are you referring to Zen Cart (Admin->Configuration->Sessions) settings,

Yes, that is where I looked to make that comment.

Host is moving everything to a 'newer' box in the next few days so I am hesitant to ask for changes right now, even if I had any idea of changes to make.

[DrByte]

You could ask for a list of differences, or the php.ini from each server to compare them yourself


I'm also mindful that the presence of any myDebug-xxxx.logs in your /logs/ folder can be helpful in this situation.

[RixStix]

I'm also mindful that the presence of any myDebug-xxxx.logs in your /logs/ folder can be helpful in this situation.

The only file there is SIM_myDebug-xxxx which contains the data sent to auth.net SIM to populate the form prior to clicking the "Pay Now" button on the auth.net SIM form.

Server log shows auth.net responding as indicated in post #3 above

[DrByte]

Okay, so checkout_process is aborting. Otherwise the log file would also contain the response details.

When that's happening, the customer is seeing the browser do things. What are they seeing?
Obviously they see the authnet site before they click "Pay", and then later they eventually see something on your site. What's that? And, what are they seeing in-between, even if only for a nanosecond? (Maybe a screen recording might show the URL change a couple times before the screen redirects?)

Is the apache errorlog showing any 406 responses? or any other non-200 responses?