Integration and Testing

[hojo]

I am using accept.js to handle a credit card form (our own form, not a hosted form). We are using almost verbatim the code provided in the accept.js documentation, with some slight modifications to handle UI things like disabling the submit button.

When the user clicks submit, we disable the button and make it say "Please wait..." while accept.js works in the background. It works great, we have posted tens of thousands of times with no issue, but we have had a small handful of users reporting the button stays at "Please wait..." and never changes. There is nothing odd in the console to indicate an error of any type. I suspect the issue is due to either a) a connectivity issue with accept.js communicating with authorize.net servers or b) some type of ad blocker preventing accept.js from working.

I have a couple questions:

1. When we call `Accept.dispatchData(secureData, responseHandler);` how long before the request times out?  

2. How do we handle (and how does authnet's accept.js handle) timeouts due to an issue with connecting to authnet's server? Is there a known best practice for this? I would imagine something like starting a timer when dispatchData is called, and running a function if X amount of time passes and the responseHandler function has not been called.

3. Are there any known issues with a certain browser plugin or ad blocker? We obviously can't control which extensions users install, but it would be nice to know if there is anything known on authnet's end. 

This has been a major thorn in my side, and a very difficult issue to track down because it doesn't seem to be traced to any specific browser/OS combo. I'm hoping someone here can help.

[ElaineM]

Hi hojo, 

I believe I am familiar with the issue you are describing, although I cannot be entirely sure. 

We know that this can happen when the user clicks the UI before it has completedly loaded, which can take a couple of seconds. Instead of getting the payment form displayed to them they see a contact "Loading" spinning wheel. 

In every reported instance of this issue I have seen it has occurred because of an implementation that has been slightly modified by the merchant to allow for an "other info" page to display, such as an additional confirmation page or the like, before proceeding to click the "Pay" button (or whatever this button has been named with the implementation). 

It occurs because the "Pay" button can be launched before the page has loaded completely. Browser console logs typically show an error such as "The target origin provided (js URL) does not match the recipient window's origin (merchant URL)". This use-case has occurred to a very small degree, to the best of our awareness, which has relied on merchant feedback and/or reports of this occurrence. 

If I am correctly assuming that you are seeing what you describe for this known cause, I can advise that our developers are currently working on an enhancement for an upcoming release to address this concern. Although we do not have an ETA for release, we are hopefull it will be soon. 

In the meantime, if possible, you may want to add in a message to ask the end-user to allow the page to complete loading before proceeding. Difficult in the impatient world we live in, but there is physically no way to prevent the end-user from clicking on the "Pay" button before the page loads completely currently. 

I hope this has been helpful to you. 

Thank you,

Elaine

[hojo]

Hey ElaineM, thanks for your reply!

So it sounds like we may be talking about the same thing. That is, a user clicking the button to submit their payment info before accept.js has fully loaded.

Are you aware of any issue, or have you heard reports of accept.js intermittently not loading due to a connectivity problem or possibly a lag in retrieving the file from Authnet's server?

I ask because no matter how hard I try, or how many times I try–I cannot reproduce the issue.