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

[shpeace]

---

@milleamy wrote:

...  I find it strange that after it times out it still is able to successfully look up the domain name and cache it...

It seems odd to me that the Silent Post URL succeeds each time this occurs.

I'm not using godaddy or a subdomain. I haven't changed TTL but until this morning hadn't had timeouts in recent days. Now having them again. :(

[TSdotNet]

At the danger of sounding like Im unnecessarily asking old questions - can I just check are we all referencing timeout on Auth.net's request for our relay response page?

I wonder if Auth.net would take this suggestion - because SIM does not rely on the output of the relay response page, they could spawn a seperate thread in their code for that request, and also increase the timeout on the request - maybe to 20 secs? Having a seperate thread of execution would mean that the Relay Response would not hold up completion of the Auth.net transaction.

It seems to me that its completely plausable that this problem could just be due to large amounts of internet traffic. I would be interested to see what Auth.net's traffic situation was at the point of these timeouts.

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

[eclair]

Just to update, the problem still exists today as of 12/10/10.

A longer timeout, or a timeout that we can customize through the x_* parameters would be excellent.  I realize 10 seconds is very consumer friendly, but sometimes, things happen and there's congestion or server's just overloaded and might take a little longer than 10 seconds.  Heck, I've bought things from major e-commerce sites and sometimes it's taken as much as 30 seconds before I got an order confirmation page!

[shpeace]

Up until Nov 23, 2010, I had a VERY few timeouts using SIM over a period of a few years, less than a handful, as I recall. In those cases both the Relay Response and Silent Post URL's failed. I always assumed it was just a network issue, nothing to be concerned about since it was exceedingly rare.

The recent timeouts have only involved the Relay Response, not the Silent Post, for my site anyway. Rather weird ... and happening frequently enough to be quite worrisome.

I wonder how seriously authorize.net is taking this? Any time things like this persist unaddressed, I start looking to jump ship. My processor has a free gateway option that is looking pretty attractive right now.

[steveddr]

I think milleamy has it pegged - a much shorter timeout for the DNS portion lookup. When I generated the error on a test order, I noticed that the time between clicking submit and receiving the error was 2 or 3 seconds at most.

eclair: A longer or customizable timeout for the page processing might be useful, but I consider it a different issue. Tech support has been giving me canned responses addressing how to fix that issue (ie. write to the page before doing anything else) but I think we've established that the connection is never made in the first place. (I also confirmed this through our server acesss and error logs, we never received the request for the relay response page when the error occurred)

shpeace: I have my own doubts about how seriously Authorize.net is taking this. I think a problem might be getting this noticed past the average tech support rep. Based on my own dealing with them, I doubt they have much technical aptitude and are instead people just trained on how to match up questions to canned responses. Although, the error affects some of us regularly, it appears to affect a very small percentage of submitted orders overall. The tech reps could be writing this off as a processing timeout (our fault) and not sending the problem to the proper channels. Even if it does go to the right people, they might not consider it a high priority based on the size of the problem. It might take someone calling and talking to the right person. I'm not technically qualified to do this as I have a limited understanding of DNS.

As for my current situation, I wanted to make the TTL change last night but was unable. As I mentioned before, I have two separate domains utilizing Authorize.net. They are basically the same store, but one was an acquired domain originally hosted out of the Netherlands. They are now both hosted on our own server, but I just realized we never changed nameservers, the original/current nameserver for the problem domain is still in the Netherlands. I'm waiting on my client to get me login information for the registrar so we can update the nameservers.

Here's a comparison of the two domains using the DNS Records tool on network-tools.com. The first one is the problem domain. We have the issue if 1 hour (3600 seconds) have passed between orders.

#####BEGIN PROBLEM DOMAIN
DNS servers
ns2.widexs.net
ns1.widexs.nl
ns3.widexs.nl

Answer records
********.com        NS    ns1.widexs.nl    15s
********.com        NS    ns3.widexs.nl    15s
********.com        A    **.**.**.***    15s
********.com        SOA    
server:    ns1.widexs.nl
email:    hostmaster@widexs.nl
serial:    2007110505
refresh:    14400
retry:    3600
expire:    604800
minimum ttl:    15
    15s
********.com        NS    ns2.widexs.net    15s

Authority records

Additional records
ns2.widexs.net        A    212.204.207.192    3600s
ns3.widexs.nl        A    62.250.7.3    300s
ns1.widexs.nl        A    212.204.192.252    300s
ns1.widexs.nl        28    [16 bytes]    300s
ns2.widexs.net        28    [16 bytes]    3600s
#####END PROBLEM DOMAIN

#####BEGIN WORKING DOMAIN
DNS servers
ns2.datapipe.net
ns1.datapipe.net

Answer records
********.com        A    **.**.**.***    14400s
********.com        NS    ns1.datapipe.net    14400s
********.com        MX    
preference:    20
exchange:    www.********.com
    14400s
********.com        NS    ns2.datapipe.net    14400s
********.com        MX    
preference:    30
exchange:    backup.mx.datapipe.net
    14400s
********.com        SOA    
server:    ns1.datapipe.net
email:    hostmaster@hispeedhosting.com
serial:    2003051200
refresh:    10800
retry:    3600
expire:    604800
minimum ttl:    14400
    14400s

Authority records

Additional records
ns1.datapipe.net        A    64.27.65.13    14400s
ns2.datapipe.net        A    64.27.64.76    14400s
www.********.com        A    **.**.**.***    14400s
#####END WORKING DOMAIN

[sportsmomict]

I am having the exact same problem and it started mid-November.  I went so far as to change hosting providers and am still having the same problem.  Very frustrating!  After reading this, I see that it definitely shows up when there hasn't been an order for awhile.  Thanks for all the helpful postings! 

I am looking at my DNS Zone records and am not sure which one(s) I need to change.  Do I just change the A record that points mydomain.com to the IP address?  Do I need to change the subdomain A records too?  Are there any others that need changed?

[eclair]

It does make me wonder about my high endorsements for Authorize.net (I tell every one of my clients to use Authorize.net if they want to accept credit cards, no ifs, ands, or buts... I don't deal with any other gateways, and they will get Authorize.net in addition to their free and existing gateways that they may already have).  I tell them Authnet is rock solid, reliable, and secure and it's the only way to go.

But it's very frustrating because like many others I'm getting canned responses from their tech support.  And how long this problem has been happening is making me feel very uncomfortable.  Surely with so many developers experiencing the same symptoms, and the "fixes" with TTL that seem to work, there should be no question that this is an Authnet issue.

Of course I was raving about Authnet to a new client and convinced them to add Authnet to their merchant account.  Now I've got egg on my face as I explain to them why an issue that has been there for weeks is still happening.

[bob_b]

An update.   I just ran my first transaction after the 1 week point  since I changed the DNS TTL value from 1 hour to 1 week and received the relay response timeout error.  Subsequent transactions worked fine and did not result in a timeout error.

Summary:  With DNS TTL set to 1 hour, relay response timeouts occur on the first transaction following a 1 hour or longer interval.  With DNS TTL set to 1 week, relay response timeouts occur on the first transaction following a 1 week or longer interval.  All subsequent transactions within the 1hour or 1 week interval work fine and never produce a timeout error.

My timeout errors, when they occur, always take 10 seconds from the time I click the submit button, consistent with the documented timeout value.  Someone indicated that theirs occured more quickly than that.  Not sure why the difference.

I've updated my original  trouble ticket with authorize.net support.  It's been open for a week and I have not received any updates from auth.net since the initial round.

It might help if each person experiencing this issue opened a ticket with support using the "contact us" link on your account page if you have not yet done that.  A large number of problem reports might result in a better response.

[steveddr]

Now that I think about it, I may have double-clicked/submitted the order on that test. In other words, submitted waited a few seconds, thought I missed the button, clicked submit again, then received the error two seconds later. Perhaps the 10 seconds did apply.

It might take us some time to have our TTL updated. It turns out the domain is owned by my client's overseas partner and I'm not sure how quickly we can get a hold of him or how quickly he can make the change.

I was thinking, would it work to have the result page be the site's dedicated IP that then redirected to the resolved name? (ie. **.**.**.**/result.php -> mydomain.com/receipt.php) It'd be ugly, but if it worked it might be our best bandaid until we had better options.

[bob_b]

I'd like to try using a dedicated IP, but right now my site with the problem uses a shared IP.  But I agree, that might be a good interim solution for those that can do it.