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

[frudesigner2010]

Wanted everyone to know two things. Just spoke with Authorize.net help desk, and they said "we are aware of the problem and our developers are looking into it."

Also, she suggested making sure that the page writes to the screen first BEFORE any other calls are made.

Of course, as soon as I started testing it, it worked on all subsequent times. I'll keep the group informed of how it ends up tomorrow.

Thanks

Chris

[pat1234]

Changing the TTL has fixed the solution so far for me.  I haven't had any user timeout issues since I've made the change.

Is there anyway that we (the few of us posting) could get notified if/when they address this issue?  Is there any kind of support ticket/bug report?

Thanks,

Pat

[TSdotNet]

if we are all subscribed to this thread we would be notified if someone posts when it is resolved.

[milleamy]

Thank you, frudesigner2010.  Our end users are extremely worried about having the timeout issue at all, whether it is 3 hours or two weeks, since the customers' credit cards would be charged without our system ever knowing that the payment was made.  It is also very difficult to find the information pertaining to the the specific transactions that timed out, since the error message which is emailed has no details at all, and so the only way to find out which one it is is to match it with a Merchant Receipt email message using the time sent.  This seems very kludgy to me-- what happens if there are two transactions made at almost the same time?  Anyway, my end user does not want to receive email receipts for every transaction.

I'm glad to hear that Authorize.net is working on it.

[eclair]

Thanks frudesigner for bringing it to Authorize.net's attention.  Please keep us updated if you hear updates from them... this is a very annoying problem!!

[steveddr]

Add me to the list of people experiencing this problem that started in November and affecting about 1/3 of our orders. Support staff has been telling me to fix the code while I've been providing evidence similar to that mentioned in this topic that it is not the code. Finally, they sent me a link to this forum. This topic was easy to find with all the activity. Like bob_b, we also have more than one domain using Authorize.net, but the intermittent problem is only affecting one of them. Thanks, btw, for the workaround. I've not had a chance to implement it yet, but I'm hopeful it will work.

[TSdotNet]

SteveDDr - when you get a look at applying the fix- could you let us know what the TTL settings are on all the domains you have integrating. If this current fix is correct, we would of course expect the site suffering from the intermitant problem to be the one with the lowest TTL.

I have a couple of thoughts to add to this discussion - the reponses are timeing out right? I dont know exactly how the normal process of pulling in the responses go, but if there was (and there would have to be) a maximum time limit set on every auth.net attempt to relay the response - and if it is the case (as I expect) that the timer for that kicks in as soon as  Auth.net's own DNS servers are queried for the URL - it would seem to me that maybe the DNS servers they use are overloaded or they are just slow. In either case - if this was the problem, they need only try out a different DNS server / service to remove the problem. Anyone else see it like this? Do you think they would consider using google DNS or something just for kicks? :)

___________________________________
<-- Kudos is always welcome....
TSdotNet

[kcrow1930]

Add us also to the list of people who have been having serious issues with SIM timing out since Mid November.  On some days almost 75% of our orders have timed out while trying to get a response from AuthorizeNet.  We have no issues at all with PayPal.  We have been getting the runaround with Tech Support at Authorizenet that it must be our servers that are having an issue our our script is not processing correctly - we have been using SIM with Authorizenet for at least 8 years and have only experienced a handful of timeout issues each year until this year.  From July until mid November 2010 we had ZERO timeout issues - then we starting experiencing timeout issues almost everyday!  We are so glad to hear that we are not the only e-tailer experiencing this problem as we were lead to believe by an Authorizenet Tech.  We are checking into using the TTL length of time change on our server to see if we can get a resolution until Authorizenet finds a way to resolve their issue.  Thank you for all your postings.

[bob_b]

tsdotnet --  That's the weird thing, I have 3 domains using the SIM method, all set up the same way.  Only one has the timeout problem.  Have not had any issues with the other two.  All 3 domains have DNS set up at godaddy.  All 3 have the default 1 hour TTL (except now I've changed the TTL of the domain with the problem to 1 week ).  All three are hosted on the same server.

There are a couple of differences.

Each of the domains have different nameservers, as those are randomly assigned by godaddy.  The problem domain uses  ns29.domaincontrol.com and ns30.domaincontrol.com.

The other two use ns11.domaincontrol.com / ns12.domaincontrol.com  and  ns03.domaincontrol.com / ns04.domaincontrol.com.  

Another difference:  the problem domain is actually a subdomain of the form  donate.mydomain.com, and the other two domains only use the domain name, i.e.  mydomain2.com and mydomain3.com.

I have no idea why  the above would make any difference in the amount of time it takes to do a lookup, but  maybe  others experiencing this  problem will recognize a pattern -- DNS at godaddy, same nameservers, use of a subdomain.

[milleamy]

As far as the timeframe for timing out, their documentation says it allows 10 seconds before it times out, but of course it is possible that they also have a shorter timeframe for the DNS lookup portion of it.  I find it strange that after it times out it still is able to successfully look up the domain name and cache it, which must be true since subsequent attempts are fine (until the TTL limit makes the cached information expire, at least if I am understand what happens correctly).  The other thing that I find interesting about the timing of all this, if what I read on various blogs is correct, there have been recent U.S. changes related to DNS servers due to the wikileaks situation.  Of course for all I know it's completely unrelated, but I have been wondering if there is a connection.