cancel
Showing results for 
Search instead for 
Did you mean: 

Authorize.NET C# SDK Bugs

Hey Guys,

Can you fix at least the following bugs in your SDK:

  1. AuthorizeNet.CustomerGateway.AddCreditCard(...)


    Replace:


    card.expirationDate = string.Format("{0}-{1}", expirationYear.ToString(), expirationMonth.ToString());

     With:

     

    card.expirationDate = String.Format(expirationYear > 99 ? "{0:D2}-{1:D4}" : "{0:D2}-{1:D2}", expirationMonth, expirationYear);

  2. AuthorizeNet.CustomerGateway.UpdateCustomer(...)

    After:

    var req = new updateCustomerProfileRequest();


    Add:

    req.profile = new customerProfileExType();
  3. AuthorizeNet.PaymentProfile.ToAPI(...)

    After:

    result.customerPaymentProfileId = this.ProfileID;

    Add:
    result.payment = new paymentType();


Web Apps Architect | .NET Engineer
koistya
Member
8 REPLIES 8

Hey there,

 

Thanks for the heads up. For each of these bugs, can you please provide a little more detail so our development teams can look into them further? Can you describe the problem you're seeing with each that led you to make these changes?

 

Thanks,

 

Michelle

Developer Community Manager

Michelle
All Star

For example, the first one can't handle dates with months from  January to September. For example if you send a Year = 2011 and a Month = 2 to the API method, it will generate "2011-2" string which your service doesn't understand, and if change it to "2011-02", then request goes smoothly, thats why {1: D2} should be used instead of {1} withing String.Format(..) there for a month.


Other spots in the SDK code throw NullReference exception making it's impossible to use CIM which is not possible to fix without patching your C# SDK.

 

In general the code quality of this C# SDK is extremly low.

 

 

Web Apps Architect | .NET Engineer

Along these lines, create unit tests for the SDK so that you can verify that everything is actually functional.

 

Thanks,

Thanks koistya and clively. I have passed on your findings to our development folk so they can make any necessary changes with the next revision.

 

Thanks,

 

Michelle

Developer Community Manager

Thanks koistya, you saved me a lot of debugging time with those fixes.

 

I would like to add that the expiration date needs to have the year first: YYYY-MM 

 

So the line should be:

card.expirationDate = String.Format(expirationYear > 99 ? "{0:D4}-{1:D2}" : "{0:D2}-{1:D2}", expirationYear, expirationMonth);
emendez77
Member

Here's another problem in the C# SDK that I stumbled on recently...

 

When using ServiceMode.Live, it makes logical sense to me that the method CustomerGateway.AddCreditCard should perform validation on the credit card data before saving it and creating a new payment profile.  However, looking at the implementation for AddCreditCard, one can see that createCustomerPaymentProfileRequest.validationMode is never set based on the type of ServiceMode given to the CustomerGateway.

 

This would be one way to fix the problem:

req.validationModeSpecified = true;
req.validationMode = this._mode == ServiceMode.Test ? validationModeEnum.testMode : validationModeEnum.liveMode;

Apologies for reviving an old thread, and if this has already been reported elsewhere, but it still appears to be an issue in the current C# SDK available for download.

 

There seems to be a bug in the constructor for CardPresentPriorAuthCapture. This constructor takes an (amount) parameter, which the documentation states will be passed as the final amount to capture:

 

    public class CardPresentPriorAuthCapture:GatewayRequest {
        /// <summary>
        /// Initializes a new instance of the <see cref="CardPresentPriorAuthCapture"/> class.
        /// </summary>
        /// <param name="transactionID">The transaction ID.</param>
        /// <param name="amount">The amount.</param>
        public CardPresentPriorAuthCapture(string transactionID, decimal amount) {
            this.SetApiAction(RequestAction.PriorAuthCapture);
            this.Queue("x_ref_trans_id", transactionID);
        }
    }

However, as you can see, the constructor never does anything with the "amount" parameter, so it is never actually passed to the gateway. Consequently, the originally-authorized amount is captured instead of the specified amount. Obviously, this is a huge problem.

 

If there's a better place to report these issues (I have run into quite a few with this SDK) please let me know.

 

Thanks,

Brian

 

 

bschoenbeck
Member

This issue has been resolved and an updated SDK is available from GitHub: https://github.com/AuthorizeNet/sdk-dotnet

 

RIchard