Your Script Timed Out / Relay Response Never Posts using SIM

[matterickson7]

All  ... I saw several old articles about this issue but I haven't seen any lately and I never saw a good solution!

Starting last week about 15% of our credit card trancations are giving hte user this message:

The reporting of this transaction to the Merchant has timed out. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.

This transaction has been approved.

It is advisable for you to contact the merchant to verify that you will receive the product or service.

I then get this e-mail from Authorize.net ... 

Authorize.Net Merchant,

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

   Transaction ID: nnnnnnnnnnnn

Transaction Result: This transaction has been approved.

After much research ... 

1. The post for the relay response never reaches our servers

2. The time out on the relay response is supposed to be 10 seconds but it happens in some cases immediately

In old threads (from 2010) I saw people changing their DNS TTL to 1 week ... I will try that.

Any other ideas?  Do I need to get off of SIM?  Authorize.net support couldn't help.

[sboyle]

@matterickson7Sorry, I'm not much of a security expert either. Our System Admin went through and disabled the TLS 1.0 and 1.1 on a bunch of our Windows 2012 Servers over the summer and I just piggy backed off one of those. 

[MikeCO]

When they put us on their payroll!

[BenPutnam]

---

@matterickson7 wrote:

It sounds like it is worth trying.  I can easily stand up a new server and point the Authorize relay reposnses to it ... 

So I am not a security expert ... what is involved in upgrading from 1.0 to 1.2?  Any good technical references?

---

The server we use is 2008 and these are the steps I followed: https://support.quovadisglobal.com/kb/a433/how-to-enable-tls-1_2-on-windows-server-2008-r2.aspx

[lmckeega]

---

@sboyle wrote:

I created an intermediate app on a server with TLS 1.2 to relay any post's coming back from Auth.net to my app that can only use TLS 1.0. I have had exactly 0 errored transactions since I did this 8 days ago.

I asked the call center no less than 3 times if the TLS upgrades could be causing this issue and the furisouly denided it.  Seems like somebody needs dig deeper on Auth.net's end.

Seems like the solution is to upgrade your host server to have TLS 1.2 as the primary cipher

---

@sboyleI have a Linux server that cannot be easily upgraded to TLS 1.2. 

Could you share more information on how you created the intermediate app? 

[sboyle]

My solution is .NET specific. I found this stackoverflow post on how to copy and relay POST messages (the answer with the checkmark). I then wrote a simple MVC web app and put it on the TLS 1.2 server. The web app receives the x_relay_url POST back from Auth.net, copies the POST body and then relays it on to my app server.

[MikeCO]

We were pretty much in the same boat though we have a new server almost ready to go, though that wasn't really relevent.

We set up a VM on the new server, running apache.  xxxx.yourdomain.com  You don't need a VM, we are just configuring this server with compartmentalized VMs so it worked well.  Used certbot to set up a free ssl cert on the new machine.  All we needed to do then is move the script that gets the response  from auth.net to the new server.  Change the response relay URL to https://xxxx.yourdomain.com/anetresponse.php and then have it send whatever you need to the old server.  In our case, it was a bit easier because the VM could actually write the db entries in postgres directly and all the references on the page were fully qualified URLs. (Pretty rare for me, lol)

The jury is still out since we just did this a short time ago, but live tested it and have had a few transactions go through without a problem. You could certainly test in sandbox too, we were just time constrained.

Only note is we had to turn on Secure client renegotiation on the new server. I'll revisit that tomorrow but we were getting an error before we did that. Might be that it was started on a different server.

[RichardH · Accepted solution]

Hello @matterickson7 @MikeCO @sboyle @lmckeega @BenPutnam

Thank you for your patience.  We heard back today from operations that some of our servers used for Relay Response were modified to require TLS 1.2.  An investigation is underway to determine why this change was made, and when, but in the mean time we've removed those servers from service which should mitigate the issue for now.

We apologize for any inconvenience this has caused and applaud you for your persistence.

Richard

[matterickson7]

Good news!

I had switched over to TLS 1.2 yesterday and we haven't had an issue since ... now is that because Authorized fixed their issue ... or because of our change?  ugh.

Thanks to all who helped us get to resolution!

RichardH ... do you know what time you made the change?

Matt

[matterickson7]

@RichardHDo you know what time the servers were taken out of service?  I would like to know if our servers were actually working under TLS 1.2 or if it was a timing coincidence that I made the change but you moved the servers our of production.

If my servers never ran under TLS 1.2 then I will need to do more testing ... 

[RichardH]

@matterickson7

We're still waiting for more details on when and why the change was made, but we've not heard any additional details.  Operations is using information from this thread to help isolate the time line.

Richard