I am in the middle of trying to track down an occasional error I'm receiving when attempting to post a credit card transacton using the AIM method with classic ASP.
I have seen at least one similar issue in this community using the SIM method.
Script issues a post to https://secure.authorize.net/gateway/transact.dll and 90% of the time all is well. However about a month ago we started seeing credit card transactions fail one moment and then magically work a few minutes later using the same information. I broke this down to a test script and sure enough about once out of every 10 to 20 attempts the script spins for while and then errors out as if something has timed out. The only errors I have to go on is the status code property from the Microsoft.XMLHTTP object which contains a value of 12019. Usually after the failure I can run the script again and it works great and will continue to work for several minutes. If I don't run it for say 10 to 15 minutes my next attempt will usually fail. After the fail the next one will go through.
The odd part is that we have two ASP sites running on two IIS7 servers. Each site is split between the servers for redundency. Site A on both servers is experiencing the same issue while Site B sails on without problem.
I don't expect anyone to have a solution right off the top of their heads, but was more curious if anyone has experienced a similar issue and if so what solutions did you find?
After some more testing this morning I may have a fix for my problem.
I created a test authorize account and every post to it succeeded without issue. So my problem resided somewhere in my application communicating solely with https://secure.authorize.net. On a whim I decided to use a different xmlhttp class object to perform the actual post. The sample code from Authorize showed using the following object: Set objRequest = Server.CreateObject("Microsoft.XMLHTTP")
I instead changed it to MSXML2.ServerXMLHTTP like so
Set objRequest = Server.CreateObject("MSXML2.ServerXMLHTTP")
Instantly the posts to https://secure.authorize.net started working and so far have not errored out. So all I can guess is that there was a break down in the communication stack using the old class. A server reboot may have flushed out the error as well but this is a production server and so I can not do that until some time third shift.
This may or may not help anyone else but I thought I'd provide the details anyway.
I'm having the exact same issue...and it's been happening since around the same time as you report first seeing it. Error / status codes aside, the most obvious result was that the .responsetext was being returned as empty string.
I'll be moving to the newer XMLHTTP stack, will report results.
Assuming this works, you've saved me a lot of time since this issue is a huge hassle to debug.