Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
12-10-2010 08:43 AM
... 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. :(
12-10-2010 09:29 AM
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....
12-10-2010 10:14 AM
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!
12-10-2010 10:30 AM
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.
12-10-2010 12:39 PM
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
********.com NS ns1.widexs.nl 15s
********.com NS ns3.widexs.nl 15s
********.com A **.**.**.*** 15s
minimum ttl: 15
********.com NS ns2.widexs.net 15s
ns2.widexs.net A 184.108.40.206 3600s
ns3.widexs.nl A 220.127.116.11 300s
ns1.widexs.nl A 18.104.22.168 300s
ns1.widexs.nl 28 [16 bytes] 300s
ns2.widexs.net 28 [16 bytes] 3600s
#####END PROBLEM DOMAIN
#####BEGIN WORKING DOMAIN
********.com A **.**.**.*** 14400s
********.com NS ns1.datapipe.net 14400s
********.com NS ns2.datapipe.net 14400s
minimum ttl: 14400
ns1.datapipe.net A 22.214.171.124 14400s
ns2.datapipe.net A 126.96.36.199 14400s
www.********.com A **.**.**.*** 14400s
#####END WORKING DOMAIN
12-10-2010 12:50 PM
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?
12-11-2010 12:55 AM
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.
12-11-2010 07:01 AM - edited 12-11-2010 07:03 AM
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.
12-11-2010 10:19 AM
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.