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

[fattyfat]

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/ind...eckout_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.

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

[fattyfat]

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.

[DrByte]

Which browser?

[fattyfat]

Firefox v3.0.14

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

[DrByte]

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.

[fattyfat]

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

[DrByte]

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

(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?

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?

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.