cancel
Showing results for 
Search instead for 
Did you mean: 

CIM Transaction Error - connection was forcibly closed by the remote host

Starting this morning (first at 11/15/2016 7:33 AM CST), we've been getting errors on some CIM payments or other CIM transactions (creating/deleting accounts).

 

The error:

 

System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send.
---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.
---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)

 

These occur sporadically and seemingly randomly, but they have continued all day (as of 5 minutes ago).  We have not seen these errors before, nor have we made any changes on our side recently.

 

Has there been some change of which we are not aware?  I see that the https://status.authorize.net/ page says that "No incidents reported today."  Consider this the report of an incident, I guess.  :)

 

(We are a reseller incidentally, and we process at least scores of payments daily, if not hundreds.)

 

Thank you!

1 ACCEPTED SOLUTION

Accepted Solutions

We do not believe this was due to any release.

 

We've reset the boxes that serve the SOAP API -- can you confirm whether the issues have cleared up?

 

If you are still seeing the issue, would you provide me with the API Login ID or Gateway ID for your Production account, please?

Also, are specific API calls being impacted here, or does it appear random?

Please bear in mind that, if I ask questions, it's because we need the information in order to investigate.

 

Thanks!

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

View solution in original post

14 REPLIES 14

Follow-up:

 

We are using the SOAP web service (https://api.authorize.net/soap/v1/Service.asmx).  We have not seen the aforementioned error before today, to our knowledge.

Hello @anetdevcommacct

I've reported your issue to the product team for analysis.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

Good idea.  Thanks!

@anetdevcommacct Is this issue with your sandbox or production account?

Production, RichardH.

Thank you for all the details, @anetdevcommacct.

 

Any chance you can capture the raw HTTP activity using Wireshark, Fiddler, or the like? It might shed more light into the errors you're currently seeing.

If you can capture it, please provide a text export of the capture, so we can review it promptly.

 

Thanks!

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

Hi, Lilith.  Thank you for your response.

 

Unfortunately, we cannot capture the raw http activity for production CIM transactions (payments, deleting/creating profiles) that occurred in the past.

 

I guess the question comes down to this:

 

1. Do you or your developers or IT department know of any kind of change in your code or servers or general infrastructure that occurred yesterday (11/16/2016) between about 7:00 AM and 5:00 PM CST that would have caused the intermittent and seemingly random errors (same transaction fails one second, works the next) noted in my original post?

 

Please answer that question (preferrably without asking me yet another question) so that we can determine if we need to look elsewhere to pinpoint the problem and help prevent it or better recover from it.  Nothing changed on our side, to our knowledge.  If nothing changed on your end either, then we need to know that.  If it is not possible for you to answer the question, then you can just tell me that, please.

 

Thank you!

Another request -- please provide your Production Gateway ID or API Login ID, as soon as possible.

If you're providing the raw HTTP output, the API Login ID will be in that datastream, but either way it'll help to know which account we need to examine.

--
"Move fast and break things," out. "Move carefully and fix what you break," in.

I'm sorry, Lilith.  I can't provide that.  Please see my question for you in my previous post.  That's the only question that I have.  If you cannot answer that question, then please just tell me that you cannot answer that question (no need to explain unless you want to).

 

Thank you.  I appreciate your work.