cancel
Showing results for 
Search instead for 
Did you mean: 

(E_WC_03) Accept.js is not loaded correctly

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.

 

22 REPLIES 22

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.

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.

aviseu
Member

Can you specify the amount of time this would impact customers without having cleared their browser cache?

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.

aviseu
Member

This happened again, our test envionment got same error.

wangleitj77
Member

I confirm that this exact issue is back.

 

For the past week or so.

icible
Contributor

Yes, this issue is back.

 

For the past week or so

icible
Contributor

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.

 

piyush_kt
Member

The same is here and also lasts for several days...

Our testing environment is affected.

Hello!

 

  1. Wouldn't you use cache: false to prevent the script from being cached?
  2. When I used this method of loading the script in a sandbox environment, the transaction went through normally.  The test credit card was accepted.  But it did not show up in a transaction search.