Authorize.Net API questions and help with your payment integration.
Authorize.Net API questions and help with your payment integration.
10-27-2010 03:57 PM
Your symptoms sound the most similar to mine, with a few exceptions:
I'm the programmer for a low-volume site, and I don't have root access on the machine to run tcpdump for days/weeks until the next failure occurs, so I can't do the same kind of debugging that you have done. Worse, the department that has hired me doesn't seem to care that I am charging them for time to manually confirm with every failure, and they don't seem to be interested in any sort of investigation into where the receipt delivery fails. But I care, and want to resolve the issue!
11-23-2010 12:40 PM - edited 11-23-2010 12:41 PM
We too are experiencing a similar issue. The first transaction run fails on the relay response, all subsequent transactions complete successfully within say 30-45 mins. If no transactions are run within that time frame, the next transaction will fail. Sounds similar to your "if it's not visible in the log" issue. Did you ever find a resolution to this problem? Authorize.net has been no help whatsoever.
11-23-2010 03:00 PM
For what it is worth, we are also experiencing a similar issue. The same exact transactions sometimes work and sometimes they produce a timeout error. I haven't actually figured out any kind of pattern to which ones work and which ones do not. I can take one that fails with a timeout error and do the exact same thing a minute later, and it will go through just fine.
08-06-2011 08:54 AM
For what it's worth, the SIM method with a relay URL worked perfectly for years prior to the data center fire of July 3, 2009. Right after that fire, when they moved into their backup data center, this issue began. I worked with Daryn Barney and others at Authorize.Net in uly of 2009. Not sure they ever worked hard on it, but I did find a solution. We tested and found that the issue is latency in the Authorize.Net data center. They spend almost no time letting the name server resolve. Therefore, we kicked up the TTL on our name server from the 3600 second default to 86400 seconds. You can even kick it up to a week. This forces the Authorize.net servers to avoid looking up dns info everytime there's a transaction and makes the relay URL work 99.99% of the time. You still get occasional errors if nobody uses the payment form for awhile.
My challenge now is that I am trying to get this to work on a GoDaddy server for a customer. GoDaddy will not adjust TTL on their name servers. I understand why they won't do this, but I have never found another solution.
If anyone ever finds another solution, please post it. Without another solution, the relay url is a useless feature in SIM until Authorize.net listens to this info and makes some really simple fixes.
08-08-2011 06:56 AM
Just checking in again. Has anyone out there ever recently gotten Relay Response to work with SIM? I stripped mine down to nothing more than a static call with a relay response url page that does nothing but says Made It. The Auth.net server times out immediately, not after 10 seconds like advertised. I cannot find a way to make the relay response work with SIM. Anyone??
08-08-2011 07:24 PM
09-26-2011 02:51 PM
I have been having the same problem and of course, support is pretty much useless. My problem boiled down to SSL connections preventing the script from ever firing.This may not be the same culprit as your problems but my symptoms sound the same. I did some sniffing on the server while testing and here's what was going on on our setup.
1. I can hit the script in my browser, it responds immediately but SIM spits out an error 52 (timeout after 10 seconds) but it times out immediately, not after 10 seconds.
2. When I watch apache logs my return url never fires (never requested by authorize.net)
3. tcpdump shows extta1f.authorize.net calling in but again, apache never shows the request in the logs
So this got me thinking maybe it has something to do with our self signed certificates. Of course I called support and asked if their server is picky about ssl, self signed certs anything else along those lines and they said "no, it doesn't care. The problem is with your script'. Of course 4 different support techs tell me this and I know it's bullsh*t because my script never fires. Why does it never fire you ask? Well there where protocol errors with the ssl negotiation and the connection fails before the request ever makes ti through the stack to php. Of course, if what the techs told me were true, and their servers did indeed not care about SSL protocol errors then this would not be a problem and the transaction would complete. But of course it would be a problem for one of the largest gateways to allow encrypted transactions across an ssl tunnel with protocol errors. So the designers of the SIM system, honor protocol failures and terminate the connection...as they should.
After some quick testing by defining my SIM urls to be http not https and modifying my post vars in my call out to them I get an immediate response and the URL's function perfectly. I have yet to determine if the problem is the self signed cert or if I have a common name mismatch. But I'm just going to say I'm assuming there's a problem with the keys commonname and not in with the fact it is self-signed; and when I fix that, https URL's will function. If I find it is a problem with self-signed certs I will post back to this forum with an update. If I don't post back assume I messed my keys up :-)
I had the exact same problem, except I was using a paid certificate
it turns out I had a NameVirtualHost directive in my apache server config files, which is a no-no for SSL connections
here's a useful tool for seeing if your certificate is valid:
see more resources here:
"Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol."
03-20-2012 11:36 AM
Holy Krap Batman Lots of people having this problem today
... please see my other posts .. we addressed this concern (Sans the Certificate portion)
with a simple Response.Flush() before doing our data dance to evaluate the post values sent back by AuthNet.
I wasn't even doing any database work just building a list to evaluate the returned values in another method before popping up either my receipt page or a "You failed -- no payment for you !! " --- esque.. page...based upon the results of my eval of the post data sent by AuthNet
Wow this is Comedy !!
MVC 3 .NET 4.0 C#
to the guy that asked about SIM and relay_response yes Sir .. I have it working right now.
And this template will serve all of our customers that use this MVC site template and require a Cart system..
04-05-2012 05:58 PM
My x_relay_url was working great until the other day. I don't know what happened and no code was updated from what I can tell.
Now I get the error:
"Your script timed out while we were trying to post transaction results to it."
The timeout occurs immeidately (not 10 seconds later)
Furthermore, no matter what I change the x_relay_url to, I still get the same message.
Here is what I am posting:
What has me for a loop is that it was all working great and nothing changed on my end. Is there any way to validate a relay url?