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

Hi @felixmaier1989,

 

Within the last day, we've updated the Accept.js and AcceptCore.js components, so if your browser was indeed caching an old version, that might have caused some problems. If there's any time that you'd see a similar issue when we haven't just updated the script, we'd definitely need to look into that.

 

In the meantime, I'll pass on your suggestions to see if there's anything else we can do to avoid cache-related errors around the time of an update to the scripts on our end.

Aaron
All Star

Hi @Aaron!

 

Just wanted to add a +1 for cache-busting for Accept.js.  Our site has had several users, both customers and administrators, report E_WC_03 over the last couple of weeks.  In each case, clearing browser cache or opening a private session has resolved the issue.

 

It's definitely a problem we'd like to see addressed sooner than later, as it's costing us at least some business.

 

Thanks,

Matt

In my testing, the jstest and js.authorize.net servers both respond properly to browser requests when the browser has a cached version in play and the browser is doing the right thing. The browser will send an etag, and ask for a changed version if there's a change after the specified date, the server will respond with a 304 status code if it's not changed, and so on.

 

However, there are browser versions that may be buggy, and there are browser misconfigurations, and misbehaving proxies, and all manner of other things that could go wrong there. So, if we can improve things with the right Cache-control: header in the response, for example, that would be nice.

 

 

Edit: I originally suggested a workaround here that won't actually work since the AcceptCore.js script verifies the URL it was called from. If I had a better memory than a gnat, I would have remembered that Felix already tried the same thing with the same results upthread.

I actually still getting this error the only solution was to clear the cache of the browser but its on AccceptCore.js so maybe its just better if you guys can add a header to remove the cache completly on that file its not a big file so will not affect the performance

 

This is how I'm including the file

 

<script type="text/javascript" src="https://js.authorize.net/v1/Accept.js" charset="utf-8"></script>

BTW: Testing with chrome Version 61.0.3163.100 (Official Build) (64-bit) 

Just want to say this is happening to me as well as of this morning. Several customers called up complaining. Hopefully someone at authorize.net sees this soon. 

Hello 

 

If you're experiencing issues with your live production account, for fastest service we recommend contacting customer support by phone at 877-447-3938.

 

Richard

We've gotten reports of this from customers today as well. The Accept.js libraries need to be robust against browser caching.

ryanhoerr
Member

The same thing is occurring for us. It looks like inconsistent versions of Accept.js and AcceptCore.js are being served from the CDN, which causes the failure.

Contacting support by phone was absolutely useless. Phone support was not remotely technical, and was not able to escalate the issue. More problematic, phone support didn't seem aware that Accept.js was a first-party product supported by Authorize.net.

 

This definitely appears to be a CDN based issue; our team's best guess is a failed rollout of an update to the AcceptCore.js file to some servers.

 

Based on interaction with support, we will be moving payment processing to another provider.