SIM Relay Response Timeout

[pat1234]

I am encoutering an issue in which a user receives a timeout error about 1 out of 10 transactions.   The response form only returns a simple html page with success or failure message.  There are no links to javacsript/css/images in the response page.   I checked the server logs and there isn't any record in the apache logs of an attempted post request.   I have tried processing credit card transactions myself on the live site and get a response from 1-2 seconds.

I looked through knowledge base and made some changes based on suggestions but still receiving the occasional timeout error.

Any suggestion?  Maybe Apache/PHP post settings for faster response?

Thanks,

Pat

[microweb]

Elaine -

The web page is accessible.  In fact, the SIM method contacts it and the code on it runs successfully (which can be confirmed by changes made in our database).  It just generates the timeout after the code has run.    I can go to the url in my browser and it displays just fine.

I can say that the files on the website have not changed at all and everything was working perfectly.

Our hosting provider recently moved all of their servers to a new location.  The new servers are cloud servers so they have hyperserv installed on them.  I'm not sure if this would cause the delay.  I do know that I had issues with these servers losing "ticks" so my timestamp was off, I've corrected that issue by subtracting the 20 minute difference.

Without getting any additional information from Authorize.net,  this is impossible for me to troubleshoot on myside.  If the time out is caused because of an error on the return page I can't see that information.

-Carol Paprotna

Microweb Design

[TrendResults1]

I was receiving this timeout error as well ... 100% of the time ... my php script on the relay response URL was executing perfectly, but the timeout error was still display regardless.

Problem seems to be that my script was executing BEFORE I output any HTML to the page. So I just wrote the headers first, then included the script in the body of my HTML page. Worked flawlessly.

Too bad there isn't any documentation on this fix. I don't know if it is a hack or not (and really don't care!).

Moral of the story: output something first ... then process the POST variables.

Hope this helps someone!

Tim

[justinbmiller]

I've been wrestling with this problem for two full days with absolutely no fix. Four of our sites are effected and I seem to be getting the same runaround with all the tech desk people I've spoken to.  I have tried all the fixes and remedies in both their documentation as well as this thread. Nothing has worked and I've become pretty frustrated since I've exhausted my debugging abilities.

- I have confirmed that 100% of the pages served by our host were valid; authorize did not try to access those files during the timeout. Also, absolutely no downtime since the issue arose.

- Loading the relay response page during a timeout showed the page loading just fine.

- HTML is served before any processing of the POST data.

- Out of 360 test transactions I posted in 30 minutes, 22 of them yielded the timeout error.

Any suggestions? We're just about ready to close our accounts. I'm getting flak from above for an issue nobody is taking the blame for. I appreciate any help. Please forgive the frustration.

[TJPride]

bob_b posted this way back near the start of the thread:

An update:

I've been testing my payment form, which uses the SIM method,  on and off the past few days and have been unable to cause a relay timeout error.  So it does seem that changing the DNS TTL value from 1 hour to 1 week made it work much more reliably.  I suppose a timeout will occur the first time the payment form is used after the one week point, but that sure beats multiple times each day.  I have reported this to authorize.net support and supposedly they are looking into the cause.

The weird thing is that we have two other domains with DNS set up at the same provider (godaddy) as the domain that is experiencing the problem, and these two domains are  hosted on the same server as the problem domain, but we have not experienced any problem with these.  Three domains all set up the same way, hosted on the same server,  all using the SIM method.  One has this timeout problem, the other two do not.

Bob B.

I've noticed that on the ISP I use to connect to the Internet, there's also a lot of lag when trying to connect to a site for the first time in a little while, probably the same issue. This started in the past 2-3 months, I have no idea what's causing it. I imagine the TTL determines frequency.

[TJPride]

An update:

I've been testing my payment form, which uses the SIM method,  on and off the past few days and have been unable to cause a relay timeout error.  So it does seem that changing the DNS TTL value from 1 hour to 1 week made it work much more reliably.  I suppose a timeout will occur the first time the payment form is used after the one week point, but that sure beats multiple times each day.  I have reported this to authorize.net support and supposedly they are looking into the cause.

The weird thing is that we have two other domains with DNS set up at the same provider (godaddy) as the domain that is experiencing the problem, and these two domains are  hosted on the same server as the problem domain, but we have not experienced any problem with these.  Three domains all set up the same way, hosted on the same server,  all using the SIM method.  One has this timeout problem, the other two do not.

Bob B.

[justinbmiller]

I'll get in contact with our network administrator and try this out. It's making its way through all of our gateways. It seemed to start over the weekend with our California gateways. Now I'm getting Transaction Error Notifications from our national gateways as well. I guess it's a good thing that it's the same secure server that posts all the transactions; hopefully making this one adjustment will fix all of our problems. Thanks for the help.

[TJPride]

It'll reduce the frequency of the problem to whatever you set the TTL frequency to, anyway.

[nic73]

I am having a similar issue using the AIM method. I get a list of payment profile numbers when a customer logs into our portal site. Every 30 minutes or so when logging in, the process hangs and I get an "unable to connect to remote server" .net error. If I refresh and try again it works fine. I called support and they offered nothing telling me no issues have been reported. Another strange this is if I ping api.authorize.net or secure.authorize.net, I get a mixture of destination net unreachable mixed in with the no replies. I'm wondering if this is a routing issue? This just started happening this past weekend.

[justinbmiller]

Be sure and stay on them. They've been looking into it since yesterday. We're getting less error emails but they're still being sent. Thankfully I've been in correspondence with a very helpful help desk representative. I've been providing them with specific URLs they can use to (hopefully) re-create the problem. I was actually thinking of migrating our 10+ payment directories over to the AIM method but after reading your response I'm glad I didn't start the process. It's definitely some sort of issue with either a hop in the route or some kind of hiccup in their processing server. Either way I'd love for these emails to go away :)

[imonggo_support]

We came to this forum searching for a solution.

We are also having similar issues;  using AIM method with card present gateway.   We are getting intermittent "unable to connect to remote server" or "remote server resets the connection".  This started to happen since a week ago.

Both ping to "cardpresent.authorize.net" and trace route consistently do not work; but some how the server was able to process payments.  Can anyone explain why?

Hope they will resolve this soon. Many of our customers are dependent on Authorize.net to process payment.  At least an official explanation will help ease everyone's confusion.

Any additional information from everyone will be very much appreciated.

[johnernst]

Have moved from AIM to SIM and everything works fine except for after the CC is approved SIM throws this error.  I have read the qtmsoft.com article below and the authorize.net article below as well.  Nothing is working.  Any new ideas?  This is clearly a problem that is not fixed.  Even the TTL solution seems to be a band-aid fix as this continues to return at the end of the TTL time period. 

Authorize.net - Help - this has consumed two day of troubleshooting for my teams - I even called support and they had no knowledge of this thead or the problem.  Basically told me I was having a rare problem.  Hardly looks that way. 

Thoughts anyone?  Thanks in advance.

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

I build a page that posts a few fields to the relay URL to test that it responds to a post method and it appears to work fine.
https://www.manadoob.net/site/payment/auth-test.html

x-cart SIM article #1
http://help.qtmsoft.com/index.php?title=X-Cart:Authorize.Net#Authorize.Net_SIM_error:_Unable_to_send...

SIM article #1
https://support.authorize.net/authkb/index?page=content&id=A663&actp=search&viewlocale=en_US&searchi...

SIM article #2
http://community.developer.authorize.net/t5/Integration-and-Testing/SIM-Relay-Response-Timeout/td-p/...