About 1% of my relay responses fail. The credit card is authorized, but the relay response does not get to my application server. I checked the HTTP log files, and the relay page POST is not there. Even if the response from my page took longer than 10 seconds, there would be a reference to the POST in the log file.
I saw some older posts (2010 and 2011) similar to this and the gist seemed to be that adjusting the DNS TTL to about 1 week would at least delay this behavior. (My DNS TTL is set at 1 hour)
Did this issue get a resolution from Authorize.NET, or do developers just accept that occasionally their Relay Responses will not get returned?
02-15-2013 12:27 PM
The resolution really depends upon the cause of the failure. The change to the TTL could potentially cause a problem if the failures are due to domain name resolution errors. Our system will not retry upon a failed resolution, so faulty DNS servers can cause a lot of missed communication. If domain name resolution is the issue, then setting the TTL to 1 week means that we will only have to do it once a week and reduce the possible times when an error could occur.
With that being said, there isn't enough information here for us to know what is causing the failure, so it may not make any difference at all.
02-21-2013 03:31 PM
Were you able to resolve this issue? Without any changes on my end, Authorize.net has stopped sending relay responses for two weeks now. First, it was intermittent, but now it's evey time. I have contacted Authorize.net tech support but they say they are not developers so they can't really help. My hosting company, Heroku, says they can't help either. I have checked every setting there is, and everything seems to be fine.
Thank you very much for your help!
02-03-2014 04:54 AM
02-05-2014 10:00 PM
We're experiencing the exact same issue. Our logs seem to indicate that no request made it to our servers. I've seen this posted in a few other forms but with no real solution (changing the TTL to 1 week is not something we're willing to do and it doesn't seem to actually fix the problem). This seems to happen for about 5% of our total transactions. We have other 3rd party integrations (such as PayPal) and we seem to get responses from them without any issues so we don't think its anything on our end thats causing this. I was wondering if this is a known issue and if there is a fix for this?
Thanks,
03-25-2014 07:35 PM
I have an existing thread in the community forums as well. After a lot of various troubleshooting, it looks like I have also run into the same issue people are reporting here (Timeout occurs immediately, no indication relay response is reaching my page).
Next step in my troubleshooting was to check the Time To Live setting which some people have stated as a resolution to this problem.
I have asked my network admin about our DNS servers, and this was the response regarding the Time To Live settings.
I spoke with the admin for that server. He confirmed it is one of ours. He told me that there is no TTL setting being used and that the DNS entries use a 1 gigabyte cache which typically covers well over 1 week.
So, now I'm back to square one. My customer is trying to go live with our system and this is the last major hurdle we need to get past.
Help? (Please?)
03-26-2014 04:16 PM
I should have stated that as of my last round of testing, about 8 out of 18 payments (back to back) provided a Relay Response back to my web application.
03-26-2014 04:19 PM
Today I was able to remove the httpS from my relay response page. I performed about 6-7 successful payment transactions in a row.
So, I think we've found the issue, however ...
is it still possible to use https for the relay response page? I don't know if my customer wants the payment transaction results to be returned in an unsecure manner.
Is there a solution for this?
03-27-2014 10:53 AM
Sorry for posting on multiple threads.
It looks like the SSL issue is being addressed as we speak, and current updates can be found here:
03-27-2014 11:27 AM