cancel
Showing results for 
Search instead for 
Did you mean: 

Relay Response (SIM)

I know there are a number of threads open in regards to SIM and the relay response URL, but since those seem to be resolved and I don't see where they resolved it, I thought I'd try a new thread.

 

I am having a problem getting the relay response URL to work through the SIM method in the development environment.

 

I set up my developer account to have a default relay response URL.  I've ensured it's a valid URL and is accessible to the outside world.  It's a simple HTML form just to ensure there are no other issues with response times.  Once the checkout page submits, it the progress bar sits for 5, maybe 10 seconds then it returns the standard error message.  The Transaction Error Notification email  I receive has this in it's text:

 

Your script timed out while we were trying to post transaction results to it.

   Transaction ID: 0

Transaction Result: This transaction has been approved.

 

I've tried it with the URL in the x_relay_response_url and without it.  I'm not sure what I'm missing here.

 

This is one of the last steps I need to get this process rolling (I need to validate the returned form) but until I hit this, I was doing OK.  I had customized the header and got all the form values loaded, so I'm not a complete idiot (though stymiee may disagree on that point from his days at SPF).  But this is baffling me.

davemaxwell
Member
22 REPLIES 22

Your symptoms sound the most similar to mine, with a few exceptions:

 

 

  1. We are using a root-signed certificate (signed by Thawte)
  2. Orders were received without problems for a year and a half, until this May. 
  3. Since then, the relay receipt is successful about 80% of the time: If the relay receipt page is visible in the access_log, then the transaction will succeed; otherwise it will fail. 

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!

Hello Mathew,

 

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.

 

Thanks!

 

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.

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.

 

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??

That probably means there is something wrong with your URL or server. Can you get the page to work when you call it directly in your browser? Have you verified the proper HTTP headers are being sent by your server.

-------------------------------------------------------------------------------------------------------------------------------------------
John Conde :: Certified Authorize.Net Developer (Brainyminds) :: Official Authorize.Net Blogger

NEW! Handling Authorize.Net's Webhooks with PHP

Integrate Every Authorize.Net JSON API with One PHP Class (Sample code included)

Tutorials for integrating Authorize.Net with PHP: AIM, ARB, CIM, Silent Post
All About Authorize.Net's Silent Post

@bmarshallbri wrote:

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.

 

Symptoms.

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:

http://www.digicert.com/help/

 

see more resources here:
http://httpd.apache.org/docs/1.3/vhosts/name-based.html

"Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol."

 

also,

http://stackoverflow.com/questions/119336/ssl-error-rx-record-too-long-and-apache-ssl

 

 

Anyone know how to set up a Wordpress progress bar that captures donation amounts and adds them to the progress bar?  I really need a solution. Willing to pay for it. 

tonylocke10
Member

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..

 

Respectfully,

ChristianProgrammer

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?

steverummins
Member