Error on API request using AuthorizeNet.DLL

[dsandberg]

On specific systems only, when we call an Authorize.Net API method (production server only), we are getting the following failure: "The underlying connection was closed.  An unexpected error occurred on a receive."

In researching the web, we have found the suggestion to set webRequest.KeepAlive to false in order to address this.  We have noted that the source code for AuthorizeNet.DLL has two instances of references to webRequest.KeepAlive, and in both cases it is being set to true.

Would customizing the API DLL source code to set KeepAlive to false be a potential way of addresing this, or would doing so have negative consequences for the API's functionality in other respects?  And more generally, are there any other ideas for addressing this issue?

[Jessica754]

---

@dsandberg wrote:

On specific systems only, when we call an Authorize.Net API method (production server only), we are getting the following failure: "The underlying connection was closed.  An unexpected error occurred on a receive."

In researching the web, we have found the suggestion to set webRequest.KeepAlive to false in order to address this.  We have noted that the source code for AuthorizeNet.DLL has two instances of references to webRequest.KeepAlive, and in both cases it is being set to true.

Would customizing the API DLL source code to set KeepAlive to false be a potential way of addresing this, or would doing so have negative consequences for the API's functionality in other respects?  And more generally, are there any other ideas for addressing this issue?

---

did you get any proper solution?, I am also facing the same issue.

[dsandberg]

---

@Jessica754 wrote:

---

@dsandberg wrote:

On specific systems only, when we call an Authorize.Net API method (production server only), we are getting the following failure: "The underlying connection was closed.  An unexpected error occurred on a receive."

In researching the web, we have found the suggestion to set webRequest.KeepAlive to false in order to address this.  We have noted that the source code for AuthorizeNet.DLL has two instances of references to webRequest.KeepAlive, and in both cases it is being set to true.

Would customizing the API DLL source code to set KeepAlive to false be a potential way of addresing this, or would doing so have negative consequences for the API's functionality in other respects?  And more generally, are there any other ideas for addressing this issue?

---

did you get any proper solution?, I am also facing the same issue.

---

Not yet.

[kikmak42]

Hi @dsandberg

Are you using same version of SDKs on all the machine ? Can you share the SDK version being used on the specific machine where you are facing the issue.

Also are you getting this error for all type of API calls, like CreateTransaction, Customer Profile, Reporting ?

Also can you please share the OS version where you are running the application, as it may happen that the OS doesn't support TLS1.2.

Thanks

Kaushik

[dsandberg]

---

@kikmak42 wrote:

Hi @dsandberg

Are you using same version of SDKs on all the machine ? Can you share the SDK version being used on the specific machine where you are facing the issue.

Also are you getting this error for all type of API calls, like CreateTransaction, Customer Profile, Reporting ?

Also can you please share the OS version where you are running the application, as it may happen that the OS doesn't support TLS1.2.

Thanks

Kaushik

---

Kaushik,

We are seeing this primarily on Windows 10 workstations, but have also seen it on Windows Server 2012 and Windows Server 2016.  The API call we are currently seeing this on is createCustomerProfileRequest, although I cannot say that is the only API so affected.

Our first thought was that this might be a TLS 1.2 issue, so we made extensive efforts to make sure TLS 1.2 was functional on these systems, and don't believe that to be the problem.

The API source code version which is in use on all systems (both those that work and those that do not) is 1.9.5 (at least that is the version number reflected in the root folder of the download, which was done using the latest version on github as of 9/26/18).  We recompiled the source code using Visual Studio 2012, in order to be able to apply a required strong name to the assembly.  No modifications were made to the source code other than to apply the strong name.

[dsandberg]

I wrote a lengthy response to your questions earlier today, which I know had appeared on the forum initially because I went back to edit one line of it.  But now I don't see it anymore.  Did the forum software glitch and delete it, or was it deleted for some other reason?

[RichardH]

@dsandberg your reply somehow triggered our SPAM filter, I've restored your message.

Richard

[kikmak42]

Hi @dsandberg,

Thats odd, even I was suspecting the issue to be a TLS 1.2 issue. Also just to confirm you are not able to make a single request from those workstation to Production endpoint or is it intermediary ?

And, you are able to make a request to Sandbox environment without issue but not to Production environment.

Also I'm asumming you are using the API integrations and not the legacy AIM integration, so can you check if you are getting the following response on both the endpoints in a browser (Chrome or IE)

{"messages":{"resultCode":"Error","message":[{"code":"E00003","text":"Root element is missing."}]}}

Sandbox : https://apitest.authorize.net/xml/v1/request.api

Production : https://api.authorize.net/xml/v1/request.api

Even I did some search on Google and found there may be multiple reasons of this issue, one of them is TLS issue, as this is a very generic error, but lets try to find why its happening.

Thanks

Kaushik

[dsandberg]

---

@kikmak42 wrote:

Hi @dsandberg,

Thats odd, even I was suspecting the issue to be a TLS 1.2 issue. Also just to confirm you are not able to make a single request from those workstation to Production endpoint or is it intermediary ?

And, you are able to make a request to Sandbox environment without issue but not to Production environment.

Also I'm asumming you are using the API integrations and not the legacy AIM integration, so can you check if you are getting the following response on both the endpoints in a browser (Chrome or IE)

{"messages":{"resultCode":"Error","message":[{"code":"E00003","text":"Root element is missing."}]}}

Sandbox : https://apitest.authorize.net/xml/v1/request.api

Production : https://api.authorize.net/xml/v1/request.api

Even I did some search on Google and found there may be multiple reasons of this issue, one of them is TLS issue, as this is a very generic error, but lets try to find why its happening.

Thanks

Kaushik

---

On the specific workstations that are evidencing the problem, it is my understanding that none of the requests are succeeding.

Yes, we are using the API integrations, and on my own workstation at least (which is Windows 7 and does not have the problem), I am getting the JSON response you listed from both of those endpoints.  I may not be able to check those responses on one of the affected computers until next week, though (the persons with access to those machines are on holiday vacations right now).

I believe we have reproduced this aganst both sandbox and production on at least one of the workstations where this has been an issue.  But again, the person who actually would have done this is out this week, so I will probably not be able to confirm this fact until next week.

Thanks much for your assistance.  Let me know if you come up with any other things to check, and then I'll get back to you with confirmations of some of the above items once people begin returning from their holiday breaks.

- David