cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Acceptjs Hosted Form problem with < IE11

Customers using IE10 and before are unable to enter their credit cards in the acceptjs hosted form.  When they click the button to launch the hosted form, they either see nothing at all, or they see an empty lightbox with 'loading...'. The only way out is to press the back button. A few of the more determined customers switched browsers and re-entered all of their information and sucessfully completed the order.

 

I have verified this behaviour with IE10 and by setting the 'emulation' to IE 10 or before in IE11 and Edge.  IE11, Edge, Firefox, and Chrome work fine.

 

To isolate, I copied the example code from https://developer.authorize.net/api/reference/features/acceptjs.html to my dev server.  I only changed the data-apiLoginID and data-clientKey entries to my valid sandbox values.  I get the same results.  No error messages appear in the console.

 

My logs show that about 8% of the customers that place items in the cart are using these browsers so I can not ignore them.  Is there a known work-around?

 

sparkie
Member
7 REPLIES 7

Hello @sparkie 

 

Authorize.Net requires a TLS 1.2 connection.  Without this, any attempt to connect will fail.  Many older browsers do not have TLS 1.2 enabled by default.

 

Richard

RichardH
Administrator Administrator
Administrator

Thank you for the response...understood.  However, when I set IE10 (on Win7) options (internet options->advanced->security) to include 'Use TSL 1.2', it still fails.  Also, IE11 works, but fails when set to 'document mode = IE10' or less. This seems to be a rendering/compatability setting without individual internet settings, so I think it should support the same security settings in either mode. These 2 clues lead me to believe it is something else.

 

Richard:

 

Forgot to mention that any version of IE or Edge fails if I set the X-UA-Compatible meta tag to IE9 on the web page.  So this re-enforces the idea that it is seems to be more of a browser version compatibility issue than the underlying security setting.

 

@sparkie 

 

Not to step on anyone's toes here, but it sounds like the TLS is a dealbreaker regardless of what your issue actually is. In other words, if the customer has to enable TLS on their browser you are going to have to lose more sales than are acceptable. People aren't that technically inclined as a rule.  

 

So I think what you need to do is use some code to detect the browser version and notify the user when they have an incompatible browser. Most people have more than one browser and then use one as their primary. They can switch to another browser or update what they have. I'd make it super user friendly and have a link to the upgrade. I'd also mention something about "enhanced security features" of the updated browsers to put a positive spin on it. 

@Renaissance 

 

Point well taken. We should detect and warn about any browser/system that is not capable of TLS 1.2, since they are incompatible with the checkout. In fact, we should not even allow them to try to pay through Authorize.net.  I guess the best we could do is provide the warning, but let them continue and then provide a โ€˜call me to get CCโ€™ button or such instead. We can determine their protocol level by parsing the SSL_PROTOCOL environmental var under Apache to see what protocol they negotiated when they connected to the cart.

 

I understand that these browsers represent < 0.5% of the general web traffic and the percentage with TLS 1.2 enabled is even less so it is possible that accessjs is not too concerned with them. But our logs show that our experience is different; they represent about 8% of the customers that actually placed items in our cart. I assume this is due to the fact our customers are generally corporate buyers placing big ticket, B2B purchases. I assume they are sticking to the old browsers for a reason and are more likely to have TLS 1.2 enabled and less likely to be allowed to make changes to their systems (and therefore unable to change/update the browser.)

 

So I would still hope to quietly support the IE9/10 users that have TLS 1.2 enabled โ€“ if possible.

 

I used IE11 to connect to our cart and examined the SSL_PROTOCOL var. Regardless of the display mode setting (IE9,10 or 11), it always connected with the highest TLS setting allowed under โ€˜internet settingsโ€™ for that system. So I am confident the problem is not TLS compatibility, but rather IE version compatibility.

 

I found a demo page <https://nexwebsites.com/authorizenet/acceptjs.aspx> that uses accessjs with embedded forms and it works fine with IE9/10 (use card : 4012888818888, future exp and any cvv), so it seems to be the something specific to the hosted form.

 

Does anyone know if accessjs with hosted forms are supposed to work with IE9/10 (assuming they support TLS 1.2), or if is it known to not be compatible?

 

@sparkie

That makes sense. I used to work for a fortune 100 corporation and we were using browsers from the dark ages. A lot of times it is because proprietary software is used and not compatible with newer browsers. For accept.js and IE < 11, I cannot answer your question. I would be searching the forum to see how many others have this issue. It would seem likely that you wouldnโ€™t be the first.

I do have a workaround for you that you may not like, but that will work. Another alternative you have is to use a hosted form with a redirect for these users. I havenโ€™t tested my PHP form with an iframe on IE< 11, but the redirect will work for sure. They are taken to an external auth.net form. So you could have a dynamically linked pay button that will direct these users to an accept hosted form like the one I use. That would catch that 8%. If you need my help with this IM me.

@Renaissance 

 

I investigated accept hosted at one time, but settled on acceptjs. I think I decided that acceptjs fit our existing cart data-flow better.

 

Thanks for the offer to help, but I have decided to make the most of the current acceptjs and see what the numbers look like. My plan:

 

1. Server-side detect โ€˜weakencryptionโ€™ = (SSL_PROTOCOL is < TLS1.2) or (browser is IE and version < 11).  If the IE9/10 incompatibility is eventually fixed or a workaround found, I can remove the 2nd condition.

 

2. On each cart page, if โ€˜weakencryptionโ€™ present a notice banner explaining the problem, suggesting they update browsers (with a link to https://browsehappy.com), but let them know they CAN continue with the current browser but will not be able to pay on-line โ€“ we will contact them for payment instead.

 

3. On the final cart page, if โ€˜weakencryptionโ€™ then offer only a โ€˜Contact me for paymentโ€™ option and leave out the acceptjs scripts. Else offer 2 payment options: โ€˜Pay now with credit cardโ€™, and โ€˜Contact me for paymentโ€™.  The latter is still useful for customers that need to pay with wire-transfers or prefer to not use their cards online.

 

I expect this will be sufficient.

 

Thanks to everyone for your input.