cancel
Showing results for 
Search instead for 
Did you mean: 

Your Script Timed Out / Relay Response Never Posts using SIM

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.

 

 

matterickson7
Contributor
70 REPLIES 70

You probably will, had several this morning.......

Mike - use the URL I previously posted for SSLLabs to see what version TLS your server supports, and then post back here what you find. Yes, it may not be a TLS version issue but all I did was port my website from old TLS 1.0 webserver to new TLS 1.2 webserver and I've not processed about 30 transactions with ZERO failures! I had 30% failure rate before the move.

 

Also, please configure a Wireshark box (or similiar) to capture all traffic between your server and Authorize.Net servers. Best if you can do it on the exterior side of your firewall, but even inside is better than nothing. Then when a failure happens check the trace and see if a Authorize.Net server attempted to contact your server, and give them that info and ask them to prove it's not their problem by providing Wireshark traces showing them communicating with your server. It will clearly show the problem (unless the communication never made it outside their server).

 

There is lots of good info in this forum thread, especially what RichardH says! There are multiple Authorize.Net customers seeing this problem. They keep telling me "you know that TLS 1.0 won't be supported after February 28, 2018, and we recommend moving to one of our newer APIs".

 

Authorize.Net could very quickly and easily prove to you (and everyone else) that it's not their problem by collecting Wireshark traces showing how communication with our servers had errors. In my case they say "here are the WinInet Error numbers our server is reporting: 12156, 12175, 122".  After analyzing those errors I posted back to them why each one showed the problem was on their end! Still no follow up on their part after I informed them of my findings.


@MikeCO wrote:

You probably will, had several this morning.......


No failures and lots of transactions posted...I'm guessing they have a server that is only allowing TLS 1.2 and we are/were occasionally hitting it.  

 

I though the TLS change was going to be major but it only took me a few minutes to change on Server 2008.

BenPutnam - your guess matches mine, that one of the Authorize.Net servers only allows TLS 1.2. Hence why I've been saying to not waste your time migrating to a new API, and either upgrade your server so that it supports TLS 1.2 or do as I did and migrate to a server that already supports TLS 1.2.

The ironic part is that if AUTHORIZE.NET HAD ACKNOWLEDGED THE ISSUE 3 WEEKS AGO, I would have had a major server upgrade done by the 18th or sooner. Instead, I've spent umteen hours (including several while I was on vacation) trying to chase this down because it is 'our fault', as well as time spent fixing the data that got screwed up by this.

There was no sense adding another server to a broken network so we backburnered the server, which would have apparently fixed the problem - IF WE KNEW THAT THEN!

How difficult would it have been to issue a statement like "we had to put a new server online that only accepts TLS 1.2, so upgrade now"? 

The IT world needs to move away from the "not our fault" answer typical of 20 years ago and just start being truthful.  I might have grumbled but I wouldn't have spent weeks chasing my tail.

MikeCO
Member

Hi there!

 

I too have been facing this issue and despite contacting them through ticket# 1-468855651, no response as yet.

 

But I am not sure if the TLS issue will resolve this since we are using SIM and the https layer of the relay response should have nothing to do with this, even if using SSL:

https://support.authorize.net/authkb/index?page=content&id=A1623&actp=search&viewlocale=en_US&search...

 

"I use Simple Checkout, so are there any changes I need to make? No changes are needed, other than ensuring that your customers are using modern/up-to-date browsers to avoid any errors or issues after February 28, 2018."

 

MikeCO, after doing this upgrade, was this issue resolved for you? If so, could you tell me know if you are using SIM or AIM?

 

Thanks!

 

Kujain,

 

The problem is the response relay needs to 'speak' to your server over a secure channel, so your server apparently needs to support TLS 1.2, by February 28th, 2018, or November 3rd, 2017, lol.

 

Our Linux server has a lot of dependencies and just compiling a TLS mod and installing it is risky that it could blow something else up.  We are going to try and  fire up the new server later today, at least in a role of webserver.  I'll keep you posted...

 

Mike

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

sboyle
Member

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?

Yet another confirmation that the issue is a TLS 1.2 issue!    If we get one more confirmation I suggest we, the customers of Authorize.Net, mark this issue as solved.

 

sboyle - how to upgrade your hosting platform to TLS 1.2 will depend on what your hosting platform is. If you are on 'Server 2008' BenPutnam posted some info for it above here.