SIM Integration Relay Response Script Timing Out Error

[whiskeyseven]

Hey Folks,

I've got a very tough issue here.

We're using the SIM Integration method, and we've got a relay response page.

We're processing several thousand transactions a day, and the vast majority of them ARE successful, so I'm fairly certain this is not a configuration issue.

HOWEVER, every so often we get a transaction that clears successfully on auth.net, but the order doesn't show up recorded in our system. Then we get the e-mail from auth.net saying "Your script timed out while we were trying to post transaction results to it. "

I can see the request to our relay response page in my access logs, so I know the request was made. Also, there is NO corresponding error in my error logs at that timestamp, so I know the page loaded.

For some reason, it seems that Auth.net's servers are having to wait more than 10 seconds (the timeout window according to the documentation) for our page to come back. There are no complex scripts on our relay response page, it's generated instantly. And, as I said above, this setup works the majority of the time.

So here's the question: how can I avoid this? Why is the timeout window so small? And if this happens, what's best-practice for recovering from it?

I wish I could talk to an actual engineer about it on the phone, but all I ever get are sales folks who direct me here to the message boards. :)

Thanks in advance for any advice...

[RichardH]

Hello everyone,

We're still working to isolate this issue, and we really appreciate the input and troubleshooting steps you have provided.  As soon as I have more information, or if we have additional questions we need answers to assist us, I'll let you know.

Richard

[comar]

Any news on this ?

[Lilith]

I wanted to clarify a few things brought up in this thread.

It is true that there is a ten-second timeout for Relay Response. That timeout begins the moment we successfully connect to your server. If there is a failure to connect, you will see the Relay Response "timeout" message immediately. In my experience, SSL/TLS negotiation issues are the biggest reason for Relay Response to fail.

To address the SSL/TLS issue, we recently installed a patch that enabled SHA-2 ciphers, which seemed to be the largest cause of the issue. At this point, we expect merchants whose SSL/TLS configuration requires SHA-2 to have no issues with accepting Relay Response data from us.

However, this patch did not address support for Server Name Indication (SNI), which allows web servers to use more than one SSL certificate, in support of multiple domains on the same server. My research suggests we may need to upgrade our web servers entirely to support this. The good news is, while I cannot divulge specific dates yet, we are moving forward with a project to upgrade those servers, currently slated for the next few months, and we can revisit SNI support after that upgrade.

----------

That said, this thread brings up intermittent issues, which suggest a single server may be misconfigured, and not constant issues that suggest a more basic issue like SNI support.

I will be asking if we can gather statistics on Relay Response errors across our transaction servers, to see if there is a single server impacted. I'll keep the thread updated on the results.

It would be helpful if those of you reporting intermittent Relay Response issues could check for SSL/TLS negotiation errors when we send the data. I believe on IIS-based servers you may need to enable WinHTTP logging first, then check the log for SSL/TLS errors. There are similar steps you may need to take on Apache servers.

[comar]

Our last succesfull transaction happened on the 14th of mars. Since then there is ALWAYS a timeout error being shown to customers. The error messge is displayed immediatelly, making the timeout message a bit odd...

So, for us it is not intermitent at all. We did not make any changes on the payment code.

We recognize anyway that it could come from a bug on our side. So we try to debug the ssl problem...

We need to find from which IP addresses the connection is attempted from (on authorize.net side). Is there any documentation for helping debug this ?

Thanks for the help

[Lilith]

There isn't a single server that handles all Relay Response data, but you should be seeing it coming from the 64.94.118.* (64.94.118.0/24) range, in both Production and Sandbox.

Let me know if you see anything in your logs.

[comar]

Ok, looking at the logs for some time. Testing with 3 transactions that where successfull.

There is nothing in the logs. Even an attempt from authorize.net... Since the last one on march 14th...

www.XXXXXXXXXX.com.log.4.gz:XXXXXXXXXX - - [14/Mar/2014:12:20:09 -0400] "GET  /cart/authnet_simdpm/order_complete?code=XXXXXXXXXX&oid=193561&pid=authnet_simdpm%7Ccommerce_payment_authnet_simdpm&type=auth_capture&msg=  HTTP/1.1" 302 5 "https://secure.authorize.net/gateway/transact.dll" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20100101 Firefox/17.0"

www.XXXXXXXXXX.com.log.4.gz:XXXXXXXXXX8  - - [14/Mar/2014:12:20:10 -0400] "GET  /checkout/193561/payment/return/XXXXXXXXXX  HTTP/1.1" 302 5 "https://secure.authorize.net/gateway/transact.dll" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20100101 Firefox/17.0"

www.XXXXXXXXXX.com.log.4.gz:XXXXXXXXXX - - [14/Mar/2014:12:20:11 -0400] "GET /checkout/XXXXXXXXXX/complete HTTP/1.1" 200 10222 "https://secure.authorize.net/gateway/transact.dll" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:17.0) Gecko/20100101 Firefox/17.0"

https://www.XXXXXXXXXX.com/admin/commerce/orders/193561/payment

This was the last successfull order that was recorded in our website. Since then all order is getting the timeout message that is given instantly after clicking the submit button on the authorize.net form.

I wonder if authorize.net even tries to connect...

[Lilith]

Did you enable HTTPS logging as described here? I can assure you we make the attempt but it's entirely possible you won't see it in the main HTTP logs because SSL/TLS fails before the actual HTTP call begins.

[comar]

I verified that the ssl log is working. yes I'm sure.

[Lilith]

But I'm not asking if SSL logging is working--I'm asking if SSL negotiation is working when we send data to you.

Next time there is a Relay Response timeout, would you check those SSL logs for any issues indicating a failure to negotiate, please?

[niroshan]

Just wondering if there are any updates on this issue? Did it turn out to be a radom misconfigured server or are you guys still looking into this?