- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ04-05-2017 09:48 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)?
โ04-05-2017 11:26 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ04-05-2017 11:29 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ04-05-2017 11:30 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.di
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.
โ04-05-2017 02:37 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ04-05-2017 02:39 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ04-05-2017 03:21 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ04-05-2017 09:22 PM

