cancel
Showing results for 
Search instead for 
Did you mean: 

CIM AuthorizeAndCapture Invalid Response on Sandbox

Hello:

 

I have just started using Authorize.net and I am using the CIM to create simple profiles, add credit cards, etc. The primary goal is to use a stored credit card for transaction purposes. I am using C#/.Net 4.5 and the SDK.  Please note, I need to actually test that CIM payment profile based transaction work BEFORE I can move to production.

 

When using test mode, the following line of code DOES NOT return what the SDK assumes it should.  If we look at CustomerGateway.cs and AuthorizeAndCapture method:

 

public IGatewayResponse AuthorizeAndCapture(Order order)...

 

It assumes the result will be populated with a "directResponse" property:

 

var response = (createCustomerProfileTransactionResponse)_gateway.Send(req);
return new GatewayResponse(response.directResponse.Split(','));

 

Stepping through the code the response seems to have NOTHING but the ANetApiResponse property "messages" populated and that simply has a result of "OK" or "Error" with a string message of "Successful" or the error code.

 

This is unacceptable because I expect this to work like other IGatewayResponse methods in the SDK (setting the Approved property, and parsing the directResponse) and I have no idea what the production result will be.  Is this just an issue on Test? How am I supposed to test this?  Has anyone else seen this with the CustomerGateway? I am using the newest code from NuGet/.Net package manager

 

<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="AuthorizeNet" version="1.8.3" targetFramework="net45" />
</packages>

 

And the HttpXmlUtility for test seems to be pointing to the standard url:

 

public const string TEST_URL = "https://apitest.authorize.net/xml/v1/request.api";

 

I have hit a brick wall here.  Can anyone shed some light on this?  AIM and AuthenticationRequests via the SDK work complete fine as well.

 

mgk145
Member
16 REPLIES 16

I wound up just using the SOAP web service directly.  You could do the same with the XML end point as well.  I am not going to touch the C# SDK code since I think it needs quite a bit of work and I can't dedicate any time to updating it via proper channels (fork of github, communicate with the creators, etc).  I'd be more inclined to try to clean up an SDK after the JSON based services are available. I read somewhere they are still in BETA.  I'd like a much cleaner web api to begin with.

I've opened this up as an issue on the github project and reported it directly to our internal developers so that they can take a look at it as soon as possible.

Added some info on our new API capabilities to use CreateTransaction with profiles and additionally how to call CreateTransaction from the SDK using the controller model.  Sample code for the scenario also added to github:

 

https://github.com/AuthorizeNet/sdk-dotnet/issues/57

 

 

 

OK, thanks for providing another SDK related method to handling this scenerio. One question however. In the test C# file I don't see what "RefId" is.  You have this in the code block:

 

var createRequest = new createTransactionRequest
{
refId = RefId,
transactionRequest = transactionRequestType
};

 

Is RefId simply a GUID or any unique identifier for the request? Or is this supposed to be populated from something else in the transaction or request?

 

Thanks

http://developer.authorize.net/api/reference/

 

refIdMerchant-assigned reference ID for the request.
If included in the request, this value will be included in the response. This feature might be especially useful for multi-threaded applications. This element is not used for mobile device requests. Use mobileDeviceId instead.
Up to 20 characters.

I couldn't agree more.

 

I've commented out the call to CheckErrors completely and have yet to notice any issues in my testing.  All my automated tests still pass with the added bonus of being able to run transactions using the CIM API methods.

 

 

Life is better, so far!

Has anyone at authorize.net even looked at this?  Only they can explain the intent of the CheckForErrors method that sets directResponse to null without resetting it to another value.  I also have been successful getting all of the CIM methods to work by simply commenting this one line of code out.  However, I would ideally like to not have to have a customized assembly and would rather simply use NuGet package manager.