cancel
Showing results for 
Search instead for 
Did you mean: 

NuGet package URLs / Logging

I'm using the Authorize.NET NuGet package, version 1.9.1 (http://www.nuget.org/packages/AuthorizeNet) in a project.  Our call to the library was modeled after the example code in the documentation of the GitHub repository (https://github.com/AuthorizeNet/sdk-dotnet).

 

On our DEV server, everything works fine [even configured to use live credentials and a live server].  But when we migrate the code over to production [same exact credentials and same live mode], it fails.  From the code perspective, we get a NULL response.  In calling Authorize.NET support, they keep saying "there's no way that we send a NULL response" but I have verified in the code that this is the case.

 

Doing network traces, we see that the request is being sent, but it looks like our credentials are being rejected from production and the connection is being terminated/dropped.  This is likely why the response is NULL because it's an unexpected termination.

 

We don't have HTTPS enabled in DEV, but we do in PROD.

 

Since we're using the NuGet package, there was no option for us to set server/environment other than the boolean flag for RunEnvironment.  We were asked to verify the servers we're using (I assume the NuGet package matches what's in the GitHub respository) and potentitally even change to the non-Akamai servers (not an option that I've seen).  Another option is to potentially turn on any logging within the library, again not an option I've seen.

 

So, how can we figure out why our connection is being terminated?  Support basically said it was either the credentials (verified to be correct) or the server (no option to change).

 

LayneRobinson
Member
4 REPLIES 4

We are having an issue with creating an arb subscription via an accept.js nonce token.  Apparently you can get an E00114 Invalid OTS Token message when the token is valid but you aren't sending the correct information.

 

I would love to learn how we could turn on logging in the NuGet package as well since we are using the same version.  As you have stated, calling Authorize.NET support hasn't helped us very much either.  I even asked if they could have their developers watch the logs as I send my request but they siad their developers don't have access to the logs.

 

So hopefully someone can help us figure out how to turn on logging for the SDK so I can then at least have the XML to send to Authorize.NET for them to verify I am (or am not) sending all the necessary data in the correct format for the Create ARB Subscription reqeust.

pmgower
Member

Hi @LayneRobinson,

 

One thing you can do is strip down the code you're using to the very most basic request. Our API supports an authentication request, where the only thing it does it check the credentials; no transaction is processed. If you're sending that type of request with bad credentials, you would expect an API response. If you get one, it's possible there's some other problem in your other code, and that becomes easier to isolate. If you send an authentication request, and still get no response at all, that's another issue.

 

Here's some code (adapted from our sample code) that I think should do the authentication test request. I didn't actually try to run it myself, yet, but the gist of it is using a authenticateTestRequest type and just sending the authentication details.

 

 

 

using System;
using System.Text;
using System.Threading.Tasks;
using System.Collections.Generic;
using AuthorizeNet.Api.Controllers;
using AuthorizeNet.Api.Contracts.V1;
using AuthorizeNet.Api.Controllers.Bases;

namespace net.authorize.sample
{
    public class TestMerchantAuthentication
    {
        public static ANetApiResponse Run(String ApiLoginID, String ApiTransactionKey)
        {
            Console.WriteLine("Authentication Test Sample");

            ApiOperationBase<ANetApiRequest, ANetApiResponse>.RunEnvironment = AuthorizeNet.Environment.PRODUCTION;

            // define the merchant information (authentication / transaction id)
            ApiOperationBase<ANetApiRequest, ANetApiResponse>.MerchantAuthentication = new merchantAuthenticationType()
            {
                name = ApiLoginID,
                ItemElementName = ItemChoiceType.transactionKey,
                Item = ApiTransactionKey,
            };


            var request = new authenticateTestRequest;

            // instantiate the contoller that will call the service
            var controller = new createTransactionController(request);
            controller.Execute();

            // get the response from the service (errors contained if any)
            var response = controller.GetApiResponse();

            // display response
            if(response != null){
			    if(response.messages.resultCode == messageTypeEnum.Ok){
					Console.WriteLine("Successful Authentication");
			    }
			    else {
				    Console.WriteLine("Failed Transaction.");
					Console.WriteLine("Error Code: " + response.messages.message[0].code);
                    Console.WriteLine("Error message: " + response.messages.message[0].text);
			    }
		    }
		    else {
			    Console.WriteLine("Null Response.");
		    }

            return response;
        }
    }
}

 

 

Any notable differences between your dev environment and your production environment? Are they on separate networks? Different firewall configurations? Is one local and one's hosted somewhere else?

 

Could you do a traceroute from each environment to api2.authorize.net?

 

Any chance you could use a tool like Postman to post the following (with Content-Type: text/xml) to https://api2.authorize.net/xml/v1/request.api?

 

 

<authenticateTestRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
<merchantAuthentication>
<name>{{your_login_id}}</name>
<transactionKey>{{your_transaction_key}}</transactionKey>
</merchantAuthentication>
</authenticateTestRequest>

 

 

Aaron
All Star

Whether or not Akamai is relevant to your issue remains to be seen, but if you did need to test against non-Akamai servers, there is a way to do that.

 

You'd have to modify the SDK itself to change the URLs used, or you could insert code into your projects to try to override where the SDK is going.

 

If you wanted to modify the SDK itself (temporarily, for testing), you'd change the files 

Authorize.NET/Utility/HttpXmlUtility.cs

and

Authorize.NET/Environment.cs

 

You'd change any references to api2.authorize.net to api.authorize.net. If you're using some of the older APIs that the SDK supports (like AIM), you'd change any references to "secure2.authorize.net" to "secure.authorize.net" in those files, but also in:

Authorize.NET/AIM/Gateway.cs

 

Aaron
All Star

Hi @pmgower,

 

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