Authorize.net SIM:Your script timed out while we were trying to post transaction resu

Hi Everyone,
My client is using ZenCart 1.3.8 with the Authorize.net SIM method.

His customers receive the following error message when completing the order in Authorize.net:
*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.
*
My client receives the following error email:
*Your script timed out while we were trying to post transaction results to it.
Transaction ID: removed
Transaction Result: This transaction has been approved.
*
When I created a test order by switching into test mode in the admin/modules/payment/SIM interface, my order was successful.

When I put my authorize.net account in test mode and created a test order, I received the error that customers saw.

After doing some research on the forums, I found that I had to input the relay response and receipt URLs into the authorize.net merchant interface. After doing so and testing an order again, it went through successfully.

At this point, I thought the problem was solved.

Today, my client said he received another error email for the latest order.

I contacted Authorize.net and they gave me the following information about "timeouts":

If this occurs only once or very rarely on an account, it is most likely unavoidable. Due to the nature of the internet, time-outs will occur on a rare occasion regardless of anything we or the developer do.

· If the error occurred many times, but all within a brief time period, it most likely indicates that there was a temporary error with their web host or web server causing it to take longer to respond than normal. This should be investigated with their web hosting company.

· If this error is occurring with any regularity, there are a few things the developer can look into:

1. The relay response URL may be invalid. This URL can be set within the merchant interface but is more commonly specified in the x_relay_url variable sent at the time of the transaction. The variable always overrides the merchant interface setting. A simple data entry error in this URL will cause this response.

2. The relay response URL may be inaccessible. This will occur if the developer has mistakenly password-protected the relay response page or is testing on a private server that is not externally accessible.

3. If this error is taking over 10 seconds to display, it is most likely a legitimate time-out error. Have the developer make sure that their page is not parsing and interpreting all of our data before actually updating their page. It is recommended that at least the page headers are printed before parsing our response.

· NOTE - Relay Response errors can sometimes be solved by simply typing the relay response URL directly into a web browser. This will clearly show if the relay response URL is invalid or inaccessible and will often make other scripting errors apparent.

My relay response and receipt URL is:
http://www.mywebsite.com/catalog/index.php?main_page=checkout_process

I verified this in debug mode and set it in authorize.net's merchant interface.

I tested the URL but putting it in the address and it showed me a "session timed out" page. I then logged in and it took me to my empty shopping cart.

So I have tested the recommendations for 1 and 2, but I do not know what authorize.net is asking in #3.

Any suggestions? My poor client is patiently upset as he has to contact customers and ask them what they bought. :no:

The AIM module isn't subject to that kind of problem. It's also more secure in preventing spoofing and in the way it handles submitted data. Is there a reason why you're not using AIM?

My client does not have a private SSL and does not like the shared SSL - so we went with the SIM method.

Here is another weird occurrence:

When I test an order the first time, I get the error message all the customers are seeing. When I push "back" in the browser, "resend" the information and then try the order again, it is successful. :blink:

Which browser?

Firefox v3.0.14

fattyfat:

DrByte:

The AIM module isn't subject to that kind of problem. It's also more secure in preventing spoofing and in the way it handles submitted data. Is there a reason why you're not using AIM?
My client does not have a private SSL and does not like the shared SSL - so we went with the SIM method.
Have you explained to this client that SSL isn't only for protecting credit card details? It also protects customer passwords, addresses, order history, etc. Protecting customers' identity information is equally important as protecting credit card information.
Private SSL certificates are not very expensive. There's seldom any legitimate excuse for not having one on your site, especially when you're collecting and displaying customer details.

What's the store URL?
It's very very possible that the problem is a combination of the speed of your store's webserver and the speed of the customer's internet connection and the computer they're using to connect to your store.

If it's taking more than 10 seconds for the page to draw when returning to your store, then something's not good with the speed of the server your store is running on.

I will reiterate the benefits of using the AIM method to my client, but I can't guarantee he'll agree.

In the meantime... currently my client is hosting their website with Network Solution's nsHosting Shared Unix package. (How do I check the speed of the server?)

Every client that has submitted an order has got the same error message, so I wouldn't think that it is their internet connection.

What I don't understand is why it works on the 2nd submission and not the first.... :blink:

fattyfat:

In the meantime... currently my client is hosting their website with Network Solution's nsHosting Shared Unix package.Enough said.
Don't even TRY to get SSL working on a Network Solutions server. Their servers are so non-standard it's impossible to write intelligent code to work with them. (Lest you desire an argument, I could enumerate tons of problems with them, many of which are discussed here in the forum. But that's another topic altogether.)
fattyfat:

(How do I check the speed of the server?)How fast do pages load?
Especially, how fast does the return from authorize.net take?
You quoted them as saying there's 10 seconds allowed. So, I ask: how long is it taking?
fattyfat:

Every client that has submitted an order has got the same error message, so I wouldn't think that it is their internet connection.Fair enough.
"Every client"? So, you're saying that the store has NEVER properly processed an order?
And how long has this store been running?
Somehow I had the impression that this was a "sudden" new problem on an otherwise-normal store. It's beginning to look a lot more like something else.

Have you confirmed whether the issue is related to certain browsers?

fattyfat:

What I don't understand is why it works on the 2nd submission and not the first....
Neither do I, but I always use AIM due to the reasons enumerated earlier. I've never found it worthwhile spending time sorting out SIM issues when AIM really is much more appropriate.

But, if you're married to Network Solutions, you'll never be able to use SSL. So you're stuck with SIM. :blink:

WOW. Knowing that about Network Solutions is real encouraging... :unsure: I am personally not a NS fan, but it is what my client already chose, so I am trying to work with it.... I know that NS is not a recommended host for ZenCart either - is there more compatibility issues I should let my client know about? Moreso, even loading pages is kind of slow on the site (opening the home page took 7-8 seconds.... ), and I have tried some recommendations in the forum to optimize it. I am beginning to think that their host is the culprit in many of these issues.... :(

Any way, the store is fairly new and only been live for about 2 months. When I originally tested the servers, I never saw a problem; it is only when real orders came through that the issue arose.

I am not sure what browsers the clients are using either - I have only tested orders with FireFox.

NOTE:
I justed tested an order with IE - ridiculously slow. :blink: When I hit the submit button on the authorize.net form it took almost 20 seconds - and I got the error message.

When I hit "back" in the browser, then "retry", I got the same message... :frusty:

In Admin->Configuration->Logging, if you turn on ONLY the "Show page parse times", that normally will show the parse times in the footer of your storefront pages.
What numbers does that give you?

HomePage:
IE - 3.192
Firefox - 1.692

Where there query times too?
What are all the times on the various pages all the way through a transaction, and through checkout?

Sorry for the delay in response - I decided to switch the site over to my server (Powweb) to see if the issue truly lied with Network Solutions....

After getting everything configured and testing an order, once I hit the submit button on the authorize.net page, I get sent back to our site with a "Whoops! Your session has expired" notification... :frusty:

Any idea why this would happen? Is there any configuration in the admin area or maybe some cache issue I can alter?

That's using SIM, right? And IE8, right?

SIM Module.

IE 7
Firefox 3

Sorry, I don't have a solution to your problem. I can't replicate the situation, and I never encounter it myself, since I never use SIM.
I strongly recommend AIM.

:cry:

Thank you for your willingness to help.

I am posting this info in case anyone else runs into the same problem.....

After switching hosts and testing it on another server, I still could not get a transaction through. I constantly received the "Whoops! Your session has expired" loophole of death. :blink:

So I switched back to our original host (Network Solutions) and tried again - and it still wasn't working.

So reading through the forums some more, I came across a thread where member Kim gave the following recommendations to set the Admin/Sessions settings to:

Cookie Domain True
Force Cookie Use False
Check SSL Session ID False
Check User Agent False
Check IP Address False
Prevent Spider Sessions True
Recreate Session False
IP to Host Conversion Status True

Here is the thread link: http://www.zen-cart.com/forum/showthread.php?t=55789

It now works! I don't know why as I thought I had these settings originally, but I am just glad I got a successful order through. I tested in FireFox and IE.

:clap: