cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Hosted 550, 90 second responses in Sandbox?

We've been testing Accept Hosted for the last couple of days on sandbox as we prepare to migrate an old Ecommerce suite to Authorize.net.

 

We got the lightbox / iframe solution working, but when we click 'pay', we're getting 'Processing' for up to 2 minutes. It was at least returning a result earlier, but now it's giving us a 550 after 102 seconds.

 

The emailed receipt comes in almost right away, so the test transaction is clearly going through in an appropirate amount of time; it's just the network request from the iframe that is taking its time.

 

Is there something going on with the sandbox Accept Hosted calls and we just have bad timing?

 

See here:

https://imgur.com/a/LXdywHd

 

Our payment request object (which is working):

 

	{
		"getHostedPaymentPageRequest": {
			"merchantAuthentication": {
				"name": "ALOGINID",
				"transactionKey": "ATRANSACTIONKEY"
			},
			"transactionRequest": {
				"transactionType": "authCaptureTransaction",
				"amount": "97.85",
				"order": {
					"invoiceNumber": "1P4-1",
					"description": "A Test Invoice (Test Child!)"
				},
				"customer": {
					"type": "individual",
					"email": "test@company.com"
				}
			},
			"hostedPaymentSettings": {
				"setting": [{
					"settingName": "hostedPaymentReturnOptions",
					"settingValue": "{\"showReceipt\":false}"
				}, {
					"settingName": "hostedPaymentButtonOptions",
					"settingValue": "{\"text\":\"Pay\"}"
				}, {
					"settingName": "hostedPaymentStyleOptions",
					"settingValue": "{\"bgColor\":\"blue\"}"
				}, {
					"settingName": "hostedPaymentPaymentOptions",
					"settingValue": "{\"cardCodeRequired\":true,\"showCreditCard\":true,\"showBankAccount\":true}"
				}, {
					"settingName": "hostedPaymentSecurityOptions",
					"settingValue": "{\"captcha\":false}"
				}, {
					"settingName": "hostedPaymentBillingAddressOptions",
					"settingValue": "{\"show\":true,\"required\":true}"
				}, {
					"settingName": "hostedPaymentCustomerOptions",
					"settingValue": "{\"showEmail\":true,\"requiredEmail\":true}"
				}, {
					"settingName": "hostedPaymentIFrameCommunicatorUrl",
					"settingValue": "{\"url\":\"https://inleague.localtest.me/includes/ecommerce/authorize-net-form.html\"}"
				}]
			}
		}
	}

 

inLeague
Contributor
10 REPLIES 10

Decided to test this with the redirect method as well just to eliminate any communication with our local machines as the culprit, and saw the same behavior. 

 

On this page:

 

 
Submitting the form is a roll of the dice: It might take 35 seconds and work, or it might take 102 seconds (exactly) and throw a 550 status code.
 
So this is the development sandbox and while it's fine if some updates are being rolled out, we're moving a six million dollar annual solution to depend on Authorize.net. Is there a status page or some place where we can go to see 'we're working on this, expect some weird behavior'? Because 'oh sorry, I don't know why that happened' is not going to fly with our clients.
inLeague
Contributor
@inLeague

Try status.authorize.net

Here is the response I typed earlier. I deleted it because I am not sure what your issue is after reading your post again.


Re: Accept Hosted 550, 90 second responses in Sandbox?
OPTIONS
‎08-17-2019 01:28 AM

@inLeague

I would say without a doubt there is something going on with your application that has nothing to do with auth.net or auth.net API. I’ve been doing this since June of 2017 and doing it full time since June of 2018, and every single client I have had has been an auth.net client. I’ve never seen anything remotely like what you are describing.

These wait times are not normal and you shouldn’t expect to get them. It could be something that you are passing in your API call. That is possible, maybe. My approach to fixing this would be to build out the most dumbed down, simplified form call possible and test it. Use the sample code on this website. Strip out anything connected to the rest of your application unless necessary. Maybe have an HTML button that calls the form and a bunch of hard coded values for amount, etc. have your return and cancel urls set to your index page. The idea is to get rid of anything remotely complicated.

You should find that this form works normally, without any huge delay like you have now. Once you’ve got that baseline, slowly build from it and incorporate it into your application, testing each step. Building one little piece at a time will help you zero in on what is breaking down.

This is painful to do but is how I often fix things like this. It will make you want to scream trying to find what is out of place. Sometimes it’s easier just to tear the whole thing down and start over. Sometimes you get lucky and find the issue very early.

We were using the most dumbed down request possible -- a redirect (even though that's not what we ultimately want to be using).

 

The token request worked just fine. We tried with a receipt and without. 

 

If there's something in our API call then the API should return an error. Our software is the obvious source of any problem. But on a redirect, the only thing our software is doing is getting a token (the complicated part, which works instantly) and performing the redirect (which works).

 

Processing a payment some of the time after 30 seconds and then throwing a 550 some of the time - who designs an API like that?

@inLeague

Post your entire API call in C# or whatever you use and I’ll look. At it. The image you posted looks like the error is coming from a .js file. Am I correct?

When I say most dumbed down form possible, I mean strip everything out. Make an html button that calls the form and hard code in every parameter. Have it completely outside of you app, meaning not one element of the form call relies on your application. Also have the minimal fields to call.

As to who designs an API like this, my friend I do not know. Auth.net does not for sure. I’ve did many of my own projects and and helped over 100 people here, and none have this issue with the API.

@Renaissance 

 

Thanks for the reply. I wonder (honestly - not trying to be sarcastic) whether the 100+ people you've helped have been using Accept Hosted, because the way you're phrasing your questions suggests that you think we're just trying to use the Authorize.net API and having problems. We're not -- the only usage of the API we have in this scenario is the initial request to get the Accept Hosted token. That part works beautifully and instantly. 

 

Once you have the token, the only 'code' is this, taken directly from the docs:

 

    <form method="post" action="'https://test.authorize.net/payment/payment" id="formAuthorizeNetPage" name="formAuthorizeNetPage">
        <input type="hidden" id="token" name="token" value="" />
        <input type="hidden" id="redirectToken" name="token" value="" />
        <div>
            <button class="button lg-btn" id="btnContinue" onclick="">Continue to Secure Payment Site</button>
        </div>
    </form>    

And then whatever JS or back-end language you want to use to populate the value of the #token field.

 

The screenshot with the JS file you're referring to is entirely the Authorize.net payment page, hosted on test.authorize.net, with their JS. I can see the source of the confusion because it's 'Api.ashx' but it's not a call from us to the Authorize.net API. It's a call from their payment page to that file on their server, which presumably is what integrates the Accept Hosted payment page with their API. That's why we stripped everything down to a redirect. There's not a single bit of our code at work after the token has been fetched.

 

And because the result is variable (sometimes it works just fine, and sometimes it doesn't) it seemed to us like somebody was just working on the Sandbox environment and it wasn't stable. I'm on vacation this week so haven't tried it since Friday morning, when it was improved from what we were seeing Thursday, but hopefully you can see that the behavior we're talking about is entirely on the Sandbox Accept Hosted site and nothing to do with us.

@inLeague 

 

In addition to the people I help here, I have 5 regular clients and they are all hosted form clients.  I have built one store from the ground up and am building another one from the ground up at the moment, and both of those were Accept Hosted.

 

What you are experiencing is bizzare. I will IM you a link to a site I use to test my first project (my UI skills are not nearly as good as my programming skills, please don't laugh. It's a beast under the hood and I am talking to the client about a interface design).  You can run a test an Accept Hosted form on it.  It is a sandbox account store. 

 

As for an outage, it is possible but hasn't been reported. If you don't get an IM from me, that means that you are not enabled for me to send, so shoot me one and I will reply with a link.  Just throw some stuff in your basked and fill out fictious details, etc. and click pay.  Hopefully that will give you a side by side.

 

I would google that js file and see what it is used for. That might give you a hint as to what causes your issue.  Js has browser compatibility issues at times. I really have no idea but best of luck to you. 

 

I'm integrating the hosted form into a client's system as well and having the same issues as @inLeague. I'm calling the API from my C# code to generate a token which I then use to do a full page redirect (per client request) to the ANet payment form. Once on the payment form I enter CC data and click the pay button.

 

I would have expected to see the receipt form but I don't get that. I've tried playing with the hosted payment settings to disable the receipt to see if it'll redirect correctly...that didn't work either.

 

Looking at the source showed the same error 550 that was identified and the same file where it's happening API.ASHX.

 

To test this I generate a token and stick it in a test html file which I use to simulate a post to the hosted form. The results are the same: token is fine, post to hosted payment form is fine, payment entry is fine, click pay --> 550/no receipt/no redirect.  I've also looked at the source for the payment form and noticed the g_* variables

 

So, I can't get a receipt to click continue, I don't get a redirect if I disable receipt and I ALWAYS get a 550.

 

I didn't see any solution posted on the forum and was wondering if it "self-resolves" as with many other issues or if there's something concrete that can be done to actually resolve it?

 

Here's the page source with sensitive details removed. Can anyone else spot something that I'm missing?

 

Thank you for your time and attention.

 

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">

<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=0">

<head id="Head1">
<title>
Secure Information
</title>
<!-- Google Tag Manager -->
<script>
(function (w, d, s, l, i) {
w[l] = w[l] || []; w[l].push({
'gtm.start':
new Date().getTime(), event: 'gtm.js'
}); var f = d.getElementsByTagName(s)[0],
j = d.createElement(s), dl = l != 'dataLayer' ? '&l=' + l : ''; j.async = true; j.src='https://www.googletagmanager.com/gtm.js?id=' + i + dl; f.parentNode.insertBefore(j, f);
})(window, document, 'script', 'dataLayer', 'GTM-KFWQGNC');</script>
<!-- End Google Tag Manager -->
<script src="https://sandbox-assets.secure.checkout.visa.com/checkout-widget/resources/js/integration/v1/sdk.js" type="text/javascript"></script>
<script type="text/javascript">
var g_token = "MY_TOKEN_HERE";
var g_merchantData =
{
"billTo":
{
"phoneNumber": null,
"faxNumber": null,
"email": "test@test.com",
"firstName": "TestFirstName",
"lastName": "TestLastName",
"company": "",
"address": "123 Main St",
"city": "Kalamazoo",
"state": "MI",
"zip": "49008",
"country": "US"
},
"shipTo": null,
"orderDescription": null,
"orderInvoiceNumber": null,
"poNumber": null,
"email": "test@test.com",
"totalAmount": "15.0000",
"currencySymbol": "$",
"currencyCode": "USD"
};
var g_pageOptions =
{
"hostedPaymentButtonOptions":
{
"text": "Submit Payment"
},
"hostedPaymentOrderOptions":
{
"show": true,
"merchantName": "Test Company"
},
"hostedPaymentShippingAddressOptions":
{
"show": false
},
"hostedPaymentBillingAddressOptions":
{
"show": true,
"required": true
},
"hostedPaymentPaymentOptions":
{
"cardCodeRequired": true,
"showCreditCard": true,
"showBankAccount": false
},
"hostedPaymentCustomerOptions":
{
"showEmail": true,
"requiredEmail": true,
"addPaymentProfile": false
},
"hostedPaymentSecurityOptions":
{
"captcha": false
},
"hostedPaymentReturnOptions":
{
"showReceipt": false,
"url": "MY_RESPONSE_URL",
"urlText": "Continue",
"cancelUrl": "MY_CANCEL_URL",
"cancelUrlText": "Cancel"
}
};
var g_paymentProfiles = null;
var g_maxPaymentProfiles = false;
var g_errorPanelMessage = "";
var g_siteKey = "MY_SITE_KEY";
var g_visaCheckoutUrl = "https://sandbox.secure.checkout.visa.com/wallet-services-web/xo/button.png";
</script>

<script type="text/javascript">
var g_EcheckEnabled = true;
var g_CreditEnabled = true;
</script>
<base href="./Scripts/v1/">
</head>
<body>
<div class="PageOuter" id="divPageOuter">
<div id="divPopupScreen" class="PopupScreen" style="display:none;"></div>
<div class="Page" id="divPage">
<div class="PageMain container" id="divPageMain container">

<!-- Google Tag Manager (noscript) -->
<noscript>
<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-KFWQGNC"
height="0" width="0" style="display:none;visibility:hidden"></iframe>
</noscript>
<!-- End Google Tag Manager (noscript) -->
<app-accept-payment></app-accept-payment>

<link href="styles.bundle.css" rel="stylesheet" />
<script type="text/javascript" src="inline.bundle.js"></script>
<script type="text/javascript" src="polyfills.bundle.js"></script>
<script type="text/javascript" src="scripts.bundle.js"></script>
<script type="text/javascript" src="main.bundle.js"></script>

</div>
<div class="PageMainAfter"></div>
</div>
</div>
</body>
</html>

 

 

 

newdjent
Member

Were you ever able to get this figured out?  We are having the exact identical issue, except it is happening to us in the production environment.  Everything works fine in the sandbox, and then when we swap out the API keys for our production one, it fails every time with the 550 status code.  We get the email receipt from the gateway, but it never does the redirect. 

I am curious as well if there was ever a resolution. I am running into the same exact thing.