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...
โ01-14-2014 08:21 AM
Little update on our side :
We had to abandon authorize.net. Mainly for lack of real and informative feedback, either in code, on the support ticket side and here.
We had several weeks wiht a big suport issue queue about this error message popin up on almost each sale.
It looks like it could be related to SSL negotiation, but our logs did log anything about this supposed negociation.
I'm still waiting for updates here and there to give authorize.net another chance. This platform is nice on a lot of other aspects.
โ05-07-2014 06:48 PM
Any further updates on this issue? We just started seeing this same issue today. We have multiple versions of a website that use essentially the same code to connect with Authorize and then get any response codes back, but now we are seeing instant "time outs" even though when we went live 11 days ago everything was working fine until today.
โ05-26-2014 01:44 PM
Hello @tlmiraglia7
Are you using Server Name Indication (SNI)? Has anything else changed in your configuration?
Richard
โ05-27-2014 09:56 AM
โ05-27-2014 02:09 PM
Here is a log that we had in the ssl debug. "no shared cipher"...
[debug] 3943#0: *135247 http recv(): 1 [debug] 3943#0: *135247 https ssl handshake: 0x16 [debug] 3943#0: *135247 SSL_do_handshake: -1 [debug] 3943#0: *135247 SSL_get_error: 1 _error.log.1:2014/04/12 23:35:47 [info] 3943#0: *135247 SSL_do_handshake() failed (SSL: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher) while SSL handshaking, client: 64.94.118.193, server: 0.0.0.0:443 [debug] 3943#0: *135247 close http connection: 28 [debug] 3943#0: *135247 SSL_shutdown: 1 [debug] 3943#0: *135247 event timer del: 28: 1397360207482 [debug] 3943#0: *135247 reusable connection: 0
โ10-14-2014 01:10 PM - last edited on โ10-14-2014 01:16 PM by RichardH
Hello @comar
We've recently seen issues reported by other community members caused by OS security updates that required a web server restart but was not automatically performed. I would recommend ensuring you have all of the latest sercurity updates applied and restart your web server.
Richard
โ10-14-2014 01:26 PM
yes @RichardH, we are up to date with security on our server.
โ10-15-2014 05:15 PM