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]

In my eTicket they attached a "Troubleshooting Template" document. It contained about 10 questions. While completing the document I added code to my website so that using a special URL my website will transfer to Authorize.Net with test mode being set to true, and the first two tries did not error, but the third try recreated the problem.

Like other have commented when the problem happened Authorize.Net did NOT attempt to connect for up to 10 seconds. Instead the error message appeared in about .1 seconds. Also, if my relay response code even starts to execute the very first thing it does is write to my homegrown logging file, and as I already knew there was nothing written.

Authorize.Net now have everything they need to to recreate the problem without anything else from us. What a major struggle this has been to get them to do anything.

[BenPutnam]

---

@bretmaverick999 wrote:

In my eTicket they attached a "Troubleshooting Template" document. It contained about 10 questions. While completing the document I added code to my website so that using a special URL my website will transfer to Authorize.Net with test mode being set to true, and the first two tries did not error, but the third try recreated the problem.

Like other have commented when the problem happened Authorize.Net did NOT attempt to connect for up to 10 seconds. Instead the error message appeared in about .1 seconds. Also, if my relay response code even starts to execute the very first thing it does is write to my homegrown logging file, and as I already knew there was nothing written.

Authorize.Net now have everything they need to to recreate the problem without anything else from us. What a major struggle this has been to get them to do anything.

---

The first thing our relay page does is write to a log as well, that is how we knew it was a problem at Authorize.NET.

[matterickson7]

Same here ... we added logging to trap the relay response.  Except ... no response.

[matterickson7]

All ... I was thinking through the issue Authorize seems to be having resolving DNS ... has anyone tried setting their relay reponse to an IP address?  I am wondering if this is an option?

[BenPutnam]

@matterickson7 wrote:

All ... I was thinking through the issue Authorize seems to be having resolving DNS ... has anyone tried setting their relay reponse to an IP address?  I am wondering if this is an option?

---

I thought about that but then your customers would have to initally access your site via IP instead of DNS or you would lose you IIS session.  As an example, if your customers initally goto mysite.com/creditcard.aspx then get redirected to 23.23.23.23/receipt.aspx but they will lose the IIS session.

We could have our customers initally access the site via IP instead of DNS but that seems like an extreme fix.  We may just move to a different credit card processing provider.

[bretmaverick999]

We should NOT having to be attempting to diagnose their poblem, but...

Do you guys know what version of TLS your server supports? I'm on an older server that only supports TLS 1.0. Suppose one of their four servers uses TLS 1.1 or 1.2, that might explain the percentage of failures we are seeing. If you aren't sure use this website to find out https://www.ssllabs.com/ssltest/index.html (opens in a new page).

I'm actually in the process of migrating to a newer server that supports TLS 1.2, but this problem is chewing up a lot of time!

[bretmaverick999]

If anybody talks to them and they say the problem isn't on their end ask them for a Wireshark capture that proves it. When I filled out the "template that outlines the information we will require to escalate this inquiry up to our engineers for further assistance" they actually asked me if I had any Wireshark captures showing "the problem". I almost fell out of my chair laughing! How can packets that never make it out of Authorize.Net's data center be captured as they enter my server? To funny! Ask them for the same thing they are asking us for. Be bold. Don't hold back. Make them attempt to prove the problem is on your end. Also, Authorize.Net is owned by Visa, so this isn't some 1-man show operating out of a log cabin.

[RichardH]

Hello @bretmaverick999, @matterickson7 @BenPutnam @sboyle @MDM

I've escalated your cases to a support specialist for further review.  

If you were not aware, SIM is now deprecated and we offer developers several choices for building SAQ A and SAQ A-EP solutions you might consider for the long term.  Learn more at http://developer.authorize.net/api/reference/features/accept.html

Richard

[RichardH]

Our support specialist indicated they are reviewing the logs and errors with our product team to see if they can isolate an issue. 

At this point, we only have a very small number merchants reporting issues with silent post so it's possible this is a service provider issue as well.  I know that doesn't help if you're one of those impacted, but we have some of our best people looking into it.

Richard

[bretmaverick999]

Thanks for your efforts @RichardH. If it helps I just had another failure today at 12:56pm MST, so have your engineers look at their Wireshark captures for a failure at that time.