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.

[bretmaverick999]

YAAF (Yet Another Authorize.net Failure) - the time of this failure was at 3:23:05pm MDT. I wonder what the Wireshark capture between my server at IP 206.130.112.238 and the four Authorize.net servers shows?

[matterickson7]

All .. after getting in touch with an actual person at Authorize they have said there is nothing more they can do.  They suggested that I re-write all my interfaces to use a "more modern" method.

[BenPutnam]

---

@matterickson7 wrote:

All .. after getting in touch with an actual person at Authorize they have said there is nothing more they can do.  They suggested that I re-write all my interfaces to use a "more modern" method.

---

Nice

[bretmaverick999]

A big clue as to why this problem is happening!!!

For a multitude of reasons I had been working on porting my website from an very old hosting platform that used TLS 1.0 to an newer hosting platform that uses TLS 1.2. I finished it up and it's now live. Since then it had three "live" transactions that passed and I just completed 10 "test" transactions and everyone of them passed. EVERY SINGLE ONE OF THEM PASSED!!!   As in 13 for 13, as in 100%!!!   Before I had about a 40% failure rate.

It has nothing to do with which method you are using, it has everything to do with what TLS version your hosting platform supports. All of my website code is the same. The only difference is it's now being hosted by a TLS 1.2 platform.

Until Authorize.Net can prove to you that migrating to a newer API will fix things I wouldn't waste my time, as my results prove moving to a newer hosting platform fixed this specific problem.

[RickDuncanCVP]

An error occurred while trying to report this transaction to the merchant. 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.

------------------------------------------------

This is the error I keep getting and it has nothing to do with the TLS platform.  

Have you been able to provide any of us with a solution?

[bretmaverick999]

Here is a URL you can use see what version of SSH / TLS your server is (opens in a new tab)

https://www.ssllabs.com/ssltest/index.html

[bretmaverick999]

The URL in my previous post rated my old website server software's SSL / TLS as "F". Exact same old website files now running on a new server and it's SSL / TLS rating is now "A-".

Remember, I even went so far as to implement a URL on my website that Authorize.Net could to help them find why this was failing. All they had to do was set up Wireshark to capture between Authorize.Net's server and my server and then use that URL. It should have taken no more than 20 minutes and they would have had everything they need to exactly why this error is happening. It was all documented in my eTicket.

Do any of you think https://www.networkworld.com would find this problem/situation interesting? 

[MikeCO]

Same error here, since 11/3, though oddly no errors Weds afternoon until this morning.  20-25% of transactions don't make it back to our server. Sometimes they all make it.

Sadly, I had checked this site on the 5th & 6th and there weren't any comments about this. So, I've had two contacts with Authorize and no one has mentioned that there is an issue. I felt is was only us having the problem so we replaced cabling, had comcast replace the router, rebooted everything with a power cord/ Cat 5e attached all to no avail. Studied router traffic logs, server utilization, etc.

My admin and I went through myriad server logs, no evidence that the relay is ever getting to the server.

Not sure how it could be a TLS error, I would think that would leave some breadcrumb on our server and I'd think it would generate a different error on their end.  In any case, 1.2 isn't required until February, and actually dealing with this crap has delayed getting our server upgraded from 1.1.

We need this fixed, I've wasted a lot of time and resources chasing this ghost and fixing transactions that errored out.

Thanks

Mike

[BenPutnam]

---

@MikeCO wrote:

Same error here, since 11/3, though oddly no errors Weds afternoon until this morning.  20-25% of transactions don't make it back to our server. Sometimes they all make it.

Sadly, I had checked this site on the 5th & 6th and there weren't any comments about this. So, I've had two contacts with Authorize and no one has mentioned that there is an issue. I felt is was only us having the problem so we replaced cabling, had comcast replace the router, rebooted everything with a power cord/ Cat 5e attached all to no avail. Studied router traffic logs, server utilization, etc.

My admin and I went through myriad server logs, no evidence that the relay is ever getting to the server.

Not sure how it could be a TLS error, I would think that would leave some breadcrumb on our server and I'd think it would generate a different error on their end.  In any case, 1.2 isn't required until February, and actually dealing with this crap has delayed getting our server upgraded from 1.1.

We need this fixed, I've wasted a lot of time and resources chasing this ghost and fixing transactions that errored out.

Thanks

Mike

---

We have not had errors since Wednesday either...

[BenPutnam]

@BenPutnam wrote:

---

@MikeCO wrote:

Same error here, since 11/3, though oddly no errors Weds afternoon until this morning.  20-25% of transactions don't make it back to our server. Sometimes they all make it.

Sadly, I had checked this site on the 5th & 6th and there weren't any comments about this. So, I've had two contacts with Authorize and no one has mentioned that there is an issue. I felt is was only us having the problem so we replaced cabling, had comcast replace the router, rebooted everything with a power cord/ Cat 5e attached all to no avail. Studied router traffic logs, server utilization, etc.

My admin and I went through myriad server logs, no evidence that the relay is ever getting to the server.

Not sure how it could be a TLS error, I would think that would leave some breadcrumb on our server and I'd think it would generate a different error on their end.  In any case, 1.2 isn't required until February, and actually dealing with this crap has delayed getting our server upgraded from 1.1.

We need this fixed, I've wasted a lot of time and resources chasing this ghost and fixing transactions that errored out.

Thanks

Mike

---

We have not had errors since Wednesday either...

---

I upgraded our server to TLS 1.2 and I thought that might have fixed it.