AcceptUI modal not opening for specific user

[dmoore]

We are working on implementing accept ui as a replacement for DPM, but one of my testers is having issues.  When she clicks on the payment button, the modal does not open, there is no information is the console, just nothing.  It works fine for her in edge, but firefox and chrome have the same behavior.  Other users are not having the same issue.  She can bring up the js file fine without any warnings, I'm stumped.  Does anybody have any ideas about what could be causing this?

Here is the code we are using:

<button type="button" id="submitBtn" class="AcceptUI button radius green left" data-billingaddressoptions="{"show":true, "required":true}" data-apiloginid="redacted" data-clientkey="redacted" data-acceptuiformbtntxt="Submit" data-acceptuiformheadertxt="Card Information" data-responsehandler="responseHandler">

                                <em class="fa fa-lock"></em> Pay <span id="paymentamount">$42.00</span>

                            </button>

I'm stumped on this and am hesitant to release it to a wider user base until we figure it out. Thanks!

[dmoore]

So a bit more information.  This specific user is using a microsoft surface.  They can use the touch screen to activate the button, however using the mouse does not work.  It seems to work fine on another surface that was tested.

[chrislav · Accepted solution]

I have the same issue with any computer that has a touchscreen, even some that don't where chrome is reporting that ontouchstart is in window

As a workaround, you can do this on click of the button:

if ("ontouchstart" in window || navigator.msMaxTouchPoints) {
    console.log("AuthorizeNet bug workaround")
 $("#AcceptUIContainer").addClass('show');
$("#AcceptUIBackground").addClass('show');
}

[robmiller20X6]

We are integrating the accept JS library and payment popup on our checkout and we are also experiencing the same issue with devices that use both touch screen and mouse. It seems that if any touch capability is detected, the mouse events aren't handled. I pretty-printed the library at https://js.authorize.net/v3/AcceptUI.js  and at the very beginning you can see where the problem is:

function e() {
        var t = document.getElementsByClassName("AcceptUI")[0],
            e = "ontouchstart" in window || navigator.msMaxTouchPoints;
        g(t, e ? "touchend" : "click", n), g(window, "message", U), a(t, m), O(), i(), d()
    }

It looks like this is selecting 'touchend' or 'click' on the basis of whether or not touch capabilities are present, but it's not handling scenarios where both are present. So when a user tries to pay with a hybrid device that uses touch and mouse, the event isn't handled and the modal popup doesn't appear.

[joeld]

We have started to implement the accept.JS method across our client sites and are getting reports of this same behavior where the payment window does not appear.   We have two laptops in our office that have the same behavior, neither have a touchscreen. 

At this point, our only option is to revert back to using a legacy method, which is unfortunate because they are legacy for some reason.

Do we have any update from Register on how this issue is being addressed?

[ezraw]

I can confirm this. Using a touchscreen HP Envy laptop and a mouse, the modal never appears.

[ezraw]

chrislav's workaround above works for us.

if ("ontouchstart" in window || navigator.msMaxTouchPoints) {
    console.log("AuthorizeNet bug workaround")
 $("#AcceptUIContainer").addClass('show');
$("#AcceptUIBackground").addClass('show');
}

[dzuczek]

RichardH, how is this "solved"?

Accept.JS shouldn't require any additional javascript per the documentation: https://developer.authorize.net/api/reference/features/acceptjs.html

Any button with "AcceptUI" as the class will have javascript actions attached to it to show the payment form.

This needs to be fixed in the remote AcceptUI.js as pointed out by robmiller20X6 above

[Anurag]

Hi @dzuczek

Yes we are fixing this issue in the next Accept UI release tentatively planned in June . 

Thanks

[karenM]

Is a fix still coming?

We have been live about 3.5 weeks and have gotten several calls from customers about this issue.

Thanks,