Integration and Testing

[pat1234]

I am encoutering an issue in which a user receives a timeout error about 1 out of 10 transactions.   The response form only returns a simple html page with success or failure message.  There are no links to javacsript/css/images in the response page.   I checked the server logs and there isn't any record in the apache logs of an attempted post request.   I have tried processing credit card transactions myself on the live site and get a response from 1-2 seconds.

I looked through knowledge base and made some changes based on suggestions but still receiving the occasional timeout error.

Any suggestion?  Maybe Apache/PHP post settings for faster response?

Thanks,

Pat

[stymiee All Star]

Have you checked your Apache logs to see if any errors are being recorded? I'd say that's a good place to start investigating this.

[pat1234]

Yes I checked the both the site logs and error logs for apache.  There isn't any post request from auth.net within that timeframe.  I do see post requests from auth.net for the successful transactions (obviously).

[shpeace]

I had a couple of those yesterday too. The transaction seems to go through as normal (all looks okay at merchant interface), including posting to Silent Post URL, with that script executing just fine. I get a "Transaction Error Notification" email saying "Your script timed out while we were trying to post transaction results to it." I test page, check error logs, run a transaction. All seems fine.

[pat1234]

My client's hosting is on Amazon cloud which is not PCI compliant so I am stuck using the SIM solution (otherwise I would use AIM).  I started reading about DPM (Direct Post Method) and may try to implement that solution maybe it will solve the timeout issues plus it should provide for a better user experience.

[bob_b]

A possible fix ...

I have also recently experienced these intermittent relay response timeouts.  Sometimes it works fine and other times the customer receives the script timed out message.  I also checked our server access logs and found that there is no record of any attempt by the authorize.net server to retrieve the response page. The web server error log does not show any errors.  When I put the URL of the response page in a browser, the page is displayed quickly and correctly, and there is an entry in the server access log that indicates that the page was retrieved.  I also have the correct URL in the list of relay response URL's on the authorize.net settings page.  Since the relay response works fine some of the time, I believe I have all the correct settings in place.

I have also observed that the script timeout error occurs when there has been no online payment  for an extended period of time (approximately 1 hour).  If online payments occur fairly often, then they all seem to work fine.

I may have found a fix for this issue.  Since it appears that the authorize.net server does not even try to access the response URL in all of the cases where the script timeout occurs, I thought maybe it is a DNS lookup timeout on the authorize.net end  that is causing the problem.  The time-to-live setting for the response URL domain was set at 1 hour.  Yesterday, I changed this to 1 week, and have not been able to generate a script timeout error since then.  That's not a very long test period, but I was always able to generate the timeout error if I waited one or two hours between tests previously .  I'll keep checking on it for a few days and see if it continues to work properly.  If this is in fact the solution, I don't know why the authorize.net server seems to have trouble doing a DNS lookup on our site.  I've never noticed any delay when I do a lookup.

[pat1234]

I currently setup the relay response to show a receipt page with a success or failure.  I am using the silent post url to write the transactions to the database and/or send e-mail.

So far the silent post url has been working without issue but the user still receives the occasional timeout error.  I will look into TTL settings hopefully that will solve the issue.

Thanks for your input.

[eclair]

Thanks for this suggestion... I'm experiencing the same issue... Many times the initial transaction will fail to get a response, but if I keep testing it, each and every time starting from the 2nd transaction seems to work properly.

Definitely think Authorize.net needs to look into this ASAP.  In the meantime thanks for the suggestion on the TTL.

[bob_b]

An update:

I've been testing my payment form, which uses the SIM method,  on and off the past few days and have been unable to cause a relay timeout error.  So it does seem that changing the DNS TTL value from 1 hour to 1 week made it work much more reliably.  I suppose a timeout will occur the first time the payment form is used after the one week point, but that sure beats multiple times each day.  I have reported this to authorize.net support and supposedly they are looking into the cause.

The weird thing is that we have two other domains with DNS set up at the same provider (godaddy) as the domain that is experiencing the problem, and these two domains are  hosted on the same server as the problem domain, but we have not experienced any problem with these.  Three domains all set up the same way, hosted on the same server,  all using the SIM method.  One has this timeout problem, the other two do not.

Bob B.

[pat1234]

Our DNS is handled by godaddy as well.  We changed the TTL over the weekend and I ran through a declined transaction that timed-out.  Every transaction afterwards has not receive any timeout errors so far.  The transaction volume is greater during the week so I will have a better idea if this solves the issue later this week.

For now I'll just enter a declined tranasction every morning until this is resolved.