Integration and Testing

[sudox]

Hello world!

I am having an issue testing the hosted payment form option for authorize.NET. I used the C# API to generate a token for a hosted payment page and have tried using both iframes and redirection posts to get the hosted page, however they each give me an unantipcated error. 

"An unanticipated error occurred while processing this request. Please click your browser’s Back button to return to the previous page."

My code looks like the following:

<form id="send_hptoken" action="https://test.authorize.net/payment/payment" method="post">
<input type="hidden" name="Token" value="##Pasted Token From C# API##" />
</form>
<iframe id="load_payment" class="embed-responsive-item" name="load_payment" width="100%" height="650px" frameborder="0" scrolling="no">
</iframe>
<button type="submit" form="send_hptoken">Send</button>

When I click the button I get directed to the error page and when I set the form target to load_payment I get an error page. Any advise would be greatly apprecaited. Hopefully I'm not being completely stupid...

[Aaron · Accepted solution]

Hi @sudox,

Are you still having problems with this? If so, here's what I've found out.

I'm looking at your code, and I'm not seeing any problem with the form post to call the payment form. Nor am I seeing any problem with the process of requesting a token.  You're getting a token back, so that's fundamentally sound.

That leaves a couple of possibilities. We could have some weird problem on our end, although I'm not aware of one. Or, the other possibility is in the data you're actually encoding in the token.

When you request the token, the process that creates the token doesn't actually do a lot of checking of the values that you're sending beyond basic sanity checking. Since a lot of the values that you're sending in the request aren't used until the payment form is loaded or submitted, whether or not they're "valid" is dependent on what happens after the payment form gets loaded.

The general idea is to just encode everything you send in, and let the payment form figure out if it's going to work or not. It's possible that you might be sending in a value in the request that doesn't quite make sense once the payment form gets a hold of it.

It's great that you posted your token request code. Using it, I've tried to recreate what you're doing as precisely as I can, and when I do, I get the same error. I go through your token request, changing things one by one, and narrow down the problem to what you're sending for the button name, specifically the ampersand. When I take the ampersand out, it works fine.

The SDK's responsible for turning what you send into an XML formatted request to our API, and it's doing that fine, including encoding the ampersand. If I make a raw XML request myself the same way the SDK would I'd do this:

<setting>
	<settingName>hostedPaymentButtonOptions</settingName>
	<settingValue>{"text": "Finish &amp; Pay"}</settingValue>
</setting>

...and I would get the same problem.

Something's happening either in the encoding of the token where the ampersand gets encoded as some poison data that breaks the payment form on load, or the token encoding puts the ampersand in correctly, but the payment form display code breaks when it sees it (because it messes up some string parsing or something).

Either way, the workaround for you (for now) is to change the button text to something like "Finish and Pay" or "Finish / Pay".

Sorry about this. Thanks so much for posting this here, though. These are the kinds of bugs I love: takes some work to figure out how to reproduce, but 100% reproducible when you do. I'll get this escalated right away.

[mistertaylor · Accepted solution]

On a related note, I was pointed to this thread by Support after receiveing the following error

"An unanticipated error occurred while processing this request. Please click your browser’s Back button to return to the previous page."

This was caused by not encoding the ampersands in my return and cancel urls. For reference, encoding as &amp; isn't sufficent - you must use percent-encoding (eg %26).

Thanks.

[Joy]

Hi sudox,

Can you please provide an exmaple how you are requesting for the token?

Thanks,

Joy

[sudox]

Absolutely (I figured I should have put that in to begin with but was in a hurry). I am using the API from Github https://github.com/AuthorizeNet/sdk-dotnet

Simply running that and then inserting the generated token onto the webpage. My code is as follows:

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

namespace net.authorize.sample.CustomerProfiles
{
    public class GetAnAcceptPaymentPage
    {
        public static ANetApiResponse Run(String ApiLoginID, String ApiTransactionKey, decimal amount)
        {
            Console.WriteLine("GetAnAcceptPaymentPage Sample");
            ApiOperationBase<ANetApiRequest, ANetApiResponse>.RunEnvironment = AuthorizeNet.Environment.SANDBOX;
            ApiOperationBase<ANetApiRequest, ANetApiResponse>.MerchantAuthentication = new merchantAuthenticationType()
            {
                name = ApiLoginID,
                ItemElementName = ItemChoiceType.transactionKey,
                Item = ApiTransactionKey,
            };

            settingType[] settings = new settingType[2];

            settings[0] = new settingType();
            settings[0].settingName = settingNameEnum.hostedPaymentButtonOptions.ToString();
            settings[0].settingValue = "{\"text\": \"Finish & Pay\"}";
            
            settings[1] = new settingType();
            settings[1].settingName = settingNameEnum.hostedPaymentOrderOptions.ToString();
            settings[1].settingValue = "{\"show\": true}";

            var transactionRequest = new transactionRequestType
            {
                transactionType = transactionTypeEnum.authCaptureTransaction.ToString(),    // authorize capture only
                amount = amount
            };

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

            // instantiate the contoller that will call the service
            var controller = new getHostedPaymentPageController(request);
            controller.Execute();
           
            // get the response from the service (errors contained if any)
            var response = controller.GetApiResponse();

            //validate
            if (response != null && response.messages.resultCode == messageTypeEnum.Ok)
            {
                Console.WriteLine("Message code : " + response.messages.message[0].code);
                Console.WriteLine("Message text : " + response.messages.message[0].text);
                Console.WriteLine("Token : " + response.token);
                System.IO.File.WriteAllText("token.txt", response.token);
            }
            else if (response != null)
            {
                Console.WriteLine("Error: " + response.messages.message[0].code + "  " + response.messages.message[0].text);
                Console.WriteLine("Failed to get hosted payment page");
            }

            return response;
        }
    }
}

For convenience I added the file output to make it easier to copy and paste the token into the webpage. The program does return a token everytime and has never given me any errors in generating the token.

Thanks,

Michael

[Aaron · Accepted solution]

Hi @sudox,

Are you still having problems with this? If so, here's what I've found out.

I'm looking at your code, and I'm not seeing any problem with the form post to call the payment form. Nor am I seeing any problem with the process of requesting a token.  You're getting a token back, so that's fundamentally sound.

That leaves a couple of possibilities. We could have some weird problem on our end, although I'm not aware of one. Or, the other possibility is in the data you're actually encoding in the token.

When you request the token, the process that creates the token doesn't actually do a lot of checking of the values that you're sending beyond basic sanity checking. Since a lot of the values that you're sending in the request aren't used until the payment form is loaded or submitted, whether or not they're "valid" is dependent on what happens after the payment form gets loaded.

The general idea is to just encode everything you send in, and let the payment form figure out if it's going to work or not. It's possible that you might be sending in a value in the request that doesn't quite make sense once the payment form gets a hold of it.

It's great that you posted your token request code. Using it, I've tried to recreate what you're doing as precisely as I can, and when I do, I get the same error. I go through your token request, changing things one by one, and narrow down the problem to what you're sending for the button name, specifically the ampersand. When I take the ampersand out, it works fine.

The SDK's responsible for turning what you send into an XML formatted request to our API, and it's doing that fine, including encoding the ampersand. If I make a raw XML request myself the same way the SDK would I'd do this:

<setting>
	<settingName>hostedPaymentButtonOptions</settingName>
	<settingValue>{"text": "Finish &amp; Pay"}</settingValue>
</setting>

...and I would get the same problem.

Something's happening either in the encoding of the token where the ampersand gets encoded as some poison data that breaks the payment form on load, or the token encoding puts the ampersand in correctly, but the payment form display code breaks when it sees it (because it messes up some string parsing or something).

Either way, the workaround for you (for now) is to change the button text to something like "Finish and Pay" or "Finish / Pay".

Sorry about this. Thanks so much for posting this here, though. These are the kinds of bugs I love: takes some work to figure out how to reproduce, but 100% reproducible when you do. I'll get this escalated right away.

[sudox]

That did the trick Aaron. Changed the text to finish and pay and got the form to appear just fine. I had considered trying to change that, but didn't follow through... Hopefully it's helpful for your team and others to know about this problem though. You may find problems with other symbol inputs especially < and >!

[Aaron]

---

@sudox wrote:

Hopefully it's helpful for your team and others to know about this problem though. You may find problems with other symbol inputs especially < and >!

---

So helpful! I really appreciate it so much when someone's willing to work with us to identify a problem rather than just posting "you guys suck!".

We'll definitely look at what all the symbols might do, not just on this form, but on our other hosted forms like our customer profile management ones.

Again, thanks!

[sudox]

Glad to help! We gotta look out for eachother. Maybe you can guide me in the right direction on how to remove the ability to select checking accounts on the hosted payment page?

[RichardH Administrator]

Hello @sudox

The payment types supported by Accept Hosted are currently controlled at the gateway.  By default, sandbox accounts are configured with both CC and ACH.  If you provide your Sandbox Gateway ID, we can remove that for you.

In a future release, we'll provide developers the option to show/hide a payment type on the request.

Richard

[sudox]

Thanks for the reply Richard. If it won't be there once we go live I'm fine with it existing while testing. Thank you for the quick reply.

[mistertaylor · Accepted solution]

On a related note, I was pointed to this thread by Support after receiveing the following error

"An unanticipated error occurred while processing this request. Please click your browser’s Back button to return to the previous page."

This was caused by not encoding the ampersands in my return and cancel urls. For reference, encoding as &amp; isn't sufficent - you must use percent-encoding (eg %26).

Thanks.