cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

CIM errors occur spordadically

I'm getting frequent unrecoverable exceptions when interacting with the CIM using the Authorize.Net SDK I obtained via NuGet.  I'm using version 1.9.1.

 

One example is with this code:

var request = new createCustomerPaymentProfileRequest

{

customerProfileId = thisUser.CustomerProfileID,

paymentProfile = ccPaymentProfile,

validationMode = validationModeEnum.testMode,

validationModeSpecified = true

};

 

var controller = new createCustomerPaymentProfileController(request);

controller.Execute();

 

Calling "Execute" results in a 500 error on the server.

 

Any ideas?  This works about 75% of the time, and then on some days it fails 75% of the time. I don't see what could be causing it.

 

pmarangoni
Contributor
7 REPLIES 7

Hi @pmarangoni,

 

Have you enabled any logging on the server or in the SDK to determine what request is being sent to Authorize.Net (if any), and what response is being received from Authorize.Net (if any)?

Aaron
All Star

No, and it's difficult to reproduce as it doesn't happen with any regularity. Once while I was stepping through with a debugger I experienced the exception, but it just blew up as soon as I called execute on the controller.

How do I enable logging in your SDK?  I don't have access to this particular server, as it's in a shared hosting environment.

Hi @pmarangoni,

 

Logging in the .NET SDK is somewhat problematic, as you have to code in a listener for Windows' ETW system.

 

Logging in the .NET SDK is handled by some classes that call system.diagnostics.trace. This is implemented in the "Authorize.NET/Util/LogHelper.cs" file.

 

If you're running the code in the IDE, any output from those calls will show up in the IDE (in the "Output" tab), but when running outside the IDE, you'd need to either run a separate debugging application, or set up a "listener" to catch that output and then write it to a file or the event log or whever you want it.

 

Here's the Microsoft article on setting up a listener: https://msdn.microsoft.com/en-us/library/system.diagnostics.tracelistener.aspx

 

 

Usually, it's a lot easier to just use something like Wireshark to do a system level network trace, but that's probably not an option in your configuration.

Yeah, that's not gonna happen. But I'm surprised that this hasn't been an issue for any of your other customers. This just started about three or four weeks ago, and it's happening with TWO of my clients.

I'm not saying that it's not an issue with anyone else. It's just that unless I know if a response is coming back bad or something else is going wrong, I don't really have any idea if it matches any other problems that anyone else might be having.

 

Generally the flow is this: Your app on your server makes some calls to the SDK. The SDK composes a request to our API and then sends that on to us. We send back a response that's (hopefully) in a format that the SDK can understand. The SDK responds back to your app the status of the request. Your app then works with the web server to respond back to the browser.

 

If anything breaks along those lines, the web server's not going to get the information it was expecting to respond to the browser, and so it's going to throw up the 500 error. We could be sending back an incorrect response that the SDK doesn't understand, so the SDK falls down. Or, the SDK gets a correct response but has some other condition that causes it to break. Or, any of those other steps could be failing.

 

There have been other reports on these forums of developers having similar sounding problems related to the path the request is taking, and possibly getting an error response returned by a CDN in that path. Without seeing the actual transaction request and response ourselves, I have no idea if this is the same case or not.

 

If you'd like, you can contact support who can open a case for you. They can possibly investigate further, although there's not much to go on in your specific case. Please be prepared to provide a traceroute from your server to api.authorize.net. 

I have opened a case with support, but thought I should post here too. Support hasn't gotten back to me with any follow up in over 24 hours.  My clients are livid.