cancel
Showing results for 
Search instead for 
Did you mean: 

OrderType is causing Unexpected error during Payment withour ordertype payment working successful

I would like to know if there are any dependencies or relationship exists with OrderType while creating CreateAnHostedPaymentPage. 

 

Reason being, when I dont add OrderType with OrderId, payment is successful

When I add OrderType with OrderId, I get unexpected error when I click on Pay button of accept hosted form within IFrame

mvkotekar1983
Contributor
23 REPLIES 23

Hi mvkotekar1983

 

Accept Hosted doesn't use an orderId element. In fact, Authorize.Net does not currently use orderId. If you are including this with your getHostedPaymentPageRequest, I would expect that an error would occur. 

 

You can review the accepted values within a getHostedPaymentPageRequest at: https://developer.authorize.net/api/reference/index.html#accept-suite-get-an-accept-payment-page

 

Can you elaborate on what you are attempting to accomplish so I can point you in the right direction? 

 

Thank you,

Elaine

ElaineM
Moderator Moderator
Moderator

I apologize for the confusion. The actual issue is around new orderType() where we define the invoiceNumber and Description details. 

 

Issue is: When we define orderType with invoiceNumber and Description, the transaction would end up in unexpected error.

 

When we remove the orderType assignment same code works for successfull payment transaction.

 

 

Here are the setting details

settingType[] settings = new settingType[5];

settings[0] = new settingType();
settings[0].settingName = settingNameEnum.hostedPaymentButtonOptions.ToString();
settings[0].settingValue = Serializer.SerializeToJson(new { text = "Pay" });

 

settings[1] = new settingType();
settings[1].settingName = settingNameEnum.hostedPaymentOrderOptions.ToString();
settings[1].settingValue = Serializer.SerializeToJson(new { show = false });

 

settings[2] = new settingType();
settings[2].settingName = settingNameEnum.hostedPaymentReturnOptions.ToString();
settings[2].settingValue = Serializer.SerializeToJson(new { showReceipt = false, url = returnUrl, urlText = "Continue", cancelUrl = cancelUrl, cancelUrlText = "Cancel" });

 

settings[3] = new settingType();
settings[3].settingName = settingNameEnum.hostedPaymentPaymentOptions.ToString();
settings[3].settingValue = Serializer.SerializeToJson(new { cardCodeRequired = false, showCreditCard = true, showBankAccount = false });

 

settings[4] = new settingType();
settings[4].settingName = settingNameEnum.hostedPaymentIFrameCommunicatorUrl.ToString();
settings[4].settingValue = Serializer.SerializeToJson(new { url = commUrl });

 

Here is the code to generate transactionRequestType

return new transactionRequestType
{
transactionType = transactionTypeEnum.authCaptureTransaction.ToString(),
amount = amount,
order = new orderType() { invoiceNumber = paymentOrderId.ToString(), description = paymentDescription }
};

 

 

Below code is used to set the appropriate details to generate the token

var paymentPageSettings = CreatePaymentPageSettings();
var transactionRequest = CreateTransactionRequest(paymentOrderId, paymentDescription, amount);

var request = new getHostedPaymentPageRequest();
request.transactionRequest = transactionRequest;
request.hostedPaymentSettings = paymentPageSettings;

Again with the disclaimer that I don’t know this language, it looks like you are declaring an instance of an object and setting property values of that object in one line. I think you would need to instantiate the ordertype object and assign it a variable, then in separate lines use method calls to set the properties.
Nope. You’re following C# syntax. I just looked it up. On second glance I think you may need to set the argument of the transaction request to Order instead of invoice and description. Order is a property of the transaction request, or order type is rather, which it appears you are assigning to a variable called order. It’s been fun helping you along. In addition to keeping me entertained while I wait for food you’ve gotten me interested in C#. Best of luck to you.

Hi, Thanks for your finding. I apologize if I didn't follow your suggestion.

 

1. I am creating instance of OrderType filling InvoiceNumber and Description field

2. Assign it to TransactionRequestType

3. TransactionRequestType is assigned to the TransactionRequest

 

Let me know if above implementation is not appropriate. (Are you saying, we need to associate ordertype to the transactionRequest directly?)

I think this line is the source of your problem-

 

var transactionRequest = CreateTransactionRequest(paymentOrderId, paymentDescription, amount);

 

what I'm not getting is why paymentOrderId and paymentDescription are in there. It looks like you are directly putting the properties of the orderType in the transaction request. Without knowing C#, I would think that you would either a) put it in there like this: 

 

var transactionRequest = CreateTransactionRequest(order, amount);

 

or b)  

 

something along the lines of-

 

var transactionRequestType = new transactionRequestType
{
transactionType = transactionTypeEnum.authCaptureTransaction.ToString(), 

amount = amount,
order = new orderType() { invoiceNumber = paymentOrderId.ToString(), description = paymentDescription }
};

 

var transactionRequest = CreateTransactionRequest(transactionRequestType);

 

And the above code I just typed is probably halfway nonsense syntactically, but it just seems odd compared to how the php API works the way this logic is laid out. 

 

It is like you are skipping one or more middlemen with this line-

 

var transactionRequest = CreateTransactionRequest(paymentOrderId, paymentDescription, amount);

 

because the orderType is a property of the transactionRequestType, and the invoiceNumber and description are properties of the orderType. 

 

So if you wanted to access the invoiceNumber in a drill down fashion it would be: 

transactionRequest->transactionRequestType->orderType->invoiceNumber

 

However, your logic to me appears to go like this:

 

transactionRequest->invoiceNumber.

 

So the API is kind of saying "you can't get there from here" in the response.

 

It would make sense that your code would run without these values, because all that is required is an amount to create a transaction request. 

 

Maybe this will help. I messed around with C# for a little bit the other day after reading your posts. It is quite a different animal, but more of the same in other ways.  Might not hurt to try. 

 

 

 

Thanks for your response, again, I apologize for the confusion. The code mentioned below is custom method I created to ensure I create the transaction type with all the details. 

 

 CreateTransactionRequest(paymentOrderId, paymentDescription, amount);

 

 

Below is the implementation of CreateTransactionRequest user defined function.

private static transactionRequestType CreateTransactionRequest(decimal paymentOrderId, string paymentDescription, decimal amount)
{
return new transactionRequestType
{
transactionType = transactionTypeEnum.authCaptureTransaction.ToString(),
amount = amount,
order = new orderType() { invoiceNumber = paymentOrderId.ToString(), description = paymentDescription }
};
}

 

As you can see one of the property order am creating a new orderType with invoice# and description. Honesty, this may not be relevant to the issue that we are facing. 

 

The payment works successfully when I don't pass orderType. 

The payment ends up with unexpected error when I pass orderType. 

 

There is some link or dependency that we are unable to identify. Or the way we are making transaction request has more or less settings.

 

 

Consolidating my 2 posts from yesterday. No worries about any confusion. The user defined function that matched an API method threw me off. I am not sure what the issue is, but my hunch is that there is some kind of noise introduced when you attempt to pass the parameters in that function to the orderType object.

I think it might be useful to try to do this without your custom function.

First define the orderType the exact same way you did in your function, and assign it to a variable. Then instead of a custom function to create the transactionRequestType you would have a variable that serves the same purposeSo you would have something like
var order = new orderType() { invoiceNumber = paymentOrderId.ToString(), description = paymentDescription }

var transactionRequest = new transactionRequestType
{
transactionType = transactionTypeEnum.authCaptureTransaction.ToString(),
amount = amount
order = order
};

My food just came out. Hope this helps.

I started having the same problem with orderType when I recently tried to switch to using the dotnet core sdk in beta (https://github.com/AuthorizeNet/dotnet-core-sdk-beta). I had previously been using the dotnet sdk and did not experience the problem in version 1.9.6 and 1.9.7 (https://github.com/AuthorizeNet/sdk-dotnet). I’ve added an issue to the dotnet core sdk with some extra details (https://github.com/AuthorizeNet/dotnet-core-sdk-beta/issues/11).

 

To summarize, the problem I have seems to be caused by the members of the orderType class. In the dotnet core sdk the class has many fields that do not exist in the dotnet sdk, such as discountAmount and purchaseOrderDateUTC. These fields are not nullable and so they get sent along with default values even if you are only setting orderType invoiceNumber or description. I can only assume this causes a problem in Authorize.Net’s system because those fields are not part of the API (https://developer.authorize.net/api/reference/#accept-suite-get-an-accept-payment-page).

 

 

This is a blocking problem preventing us from using the dotnet core sdk. Can we get an idea of when this will be resolved? Also the sdk is still in beta, but the code repository has modifications in it from 2 years ago. Is there a reason it is still in beta, and when can we expect it will be available for use in production?

mwrightmcci
Member