Today I was back at work after a few days off and when I tested paying via Accept.Js on my local environment, I had the following error message:
(E_WC_03) Accept.js is not loaded correctly
But after refreshing the page the error was gone. I was not able to reproduce the bug because I ran out of time. I believe this lies in this hash-logic which ensures compatibility between Accept.js and AcceptCore.js. Are you sure this pairing is robust against browser caching?
Why wouldnt you allow passing query parameters to https://jstest.authorize.net/v1/Accept.js ? I think is it very important that the front end can force the JS file not to be loaded from the cache with some inclusion like:
<script type="text/javascript" src="https://jstest.authorize.net/v1/Accept.js?version=<?php echo time(); ?>" charset="utf-8"></script>
Otherwise, as third-part developers implement your library and you have no control over their front end code, you cannot ensure backward compatibility.
-------------------
FYI: steps to reproduce
What I exactly did before having this bug:
1) I openend my browser (Firefox, under OSX) and made some payments (on my local dev environment) from my website to my sandbox account.
2) Three days later, I try to another payment, but on the page load (my app runs with PHP) an error "
(E_WC_03) Accept.js is not loaded correctly" is thrown
3) Assuming this is a caching issue, I change
<script type="text/javascript" src="https://jstest.authorize.net/v1/Accept.js" charset="utf-8"></script>
to
<script type="text/javascript" src="https://jstest.authorize.net/v1/Accept.js?version=<?php echo time(); ?>" charset="utf-8"></script>
in my page to force refreshing the JS file. When refreshing the page, my console says "Library is not coming from Accept CDN."
4) After reverting my change and refreshing the page, the initial error E_WC_03 was gone and I could place the payment.
03-07-2017 03:26 AM
Thanks for posting here everyone, and sorry about any difficulties you've been experiencing. We're investigating, and it looks like there was a CDN caching issue that's now been resolved. In the short term, refreshing the browser cache should clear up any lingering effects.
@wkirby, I'm so sorry about your experience with support. The heads of the support organization have been made aware so that they can investigate whatever retraining might be necessary.
10-12-2017 01:34 PM - edited 10-12-2017 01:37 PM
Hey everyone.
I confirm that AcceptCore.js has changed on the CDN (not sure about Accept.js).
Both files of the older version work, and both files of the newer version work. But since the URLs are the same I'm guessing for whatever reason we are having one of the files being cached and not the other, causing a version mismatch.
This is troubling because we have no control over our user's browser cache. Unfortunately cache busting Accept.js doesn't propagate the same effect to AcceptCore.js
To get around this issue I decided to try forcing the cacheless loading of both files (Accept.JS and AcceptCore.js).
I'm still confirming that this indeed clutched the issue but I here is what (appears) to have worked:
Original Code:
<script type="text/javascript" src="https://js.authorize.net/v1/Accept.js" charset="utf-8"></script>
New Code:
<script> $.ajaxSetup({ cache: true }); function loadScript(script) { jQuery.ajax({ async: false, type: 'GET', url: script, data: null, success: function () { console.log(script + ' force loaded'); }, dataType: 'script', error: function (xhr, textStatus, errorThrown) { console.log(script + ' ' + textStatus); } }); } loadScript('https://js.authorize.net/v1/AcceptCore.js'); loadScript('https://js.authorize.net/v1/Accept.js'); </script> <script type="text/javascript" src="https://js.authorize.net/v1/Accept.js" charset="utf-8"></script>
This, I hope, forces the fetching of the new versions of the Javascript files, which should then be used when the <script> tag requests it. Requesting it only with jQuery.ajax seems to trigger some sort of CDN enforcement protection so the <script> is still needed.
Hoping this helps anyone who is pulling their hairs out like I was.
Ideally in the future Authorize.net would be more careful with version changes on their CDN.
10-12-2017 02:05 PM - edited 10-12-2017 02:13 PM
Can you specify the amount of time this would impact customers without having cleared their browser cache?
10-16-2017 08:10 AM
Just checking in. We are still having this issue with users using iOS (safari) and OS X (chrome or safari). No idea what else I can do.
10-17-2017 07:07 PM
This happened again, our test envionment got same error.
10-24-2019 11:15 AM
I confirm that this exact issue is back.
For the past week or so.
10-29-2019 01:24 PM
Yes, this issue is back.
For the past week or so
10-29-2019 01:25 PM
It's happening for us in our Test environment.
The issue is not happening for all users but some users are affected and not able to submit test payments.
11-06-2019 05:04 AM
The same is here and also lasts for several days...
Our testing environment is affected.
11-08-2019 04:57 AM
Hello!
01-02-2020 10:17 AM