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 jonathan2019

 

This appears to be unrelated to the E_WC_03 error which is the subject of this thread, however if your transaction was successful yet cannot be found in the Merchant Interface that would imply that it was processed in Test Mode. Test Mode transactions are not stored in the system and will never be found upon review of the account. If you want to be able to locate and review the transactions, manually in UI or via API, please submit the transactions in Live Mode. 

 

Regards,

Elaine

 

Thanks, Elaine.  I have since switched to Live Mode on the Sandbox and the transactions are being recorded.  That part makes sense now.

 

However, after reviewing this thread and a few others Re: E_WC_03, it appears the issue hasn't been adequately addressed.  The error appeared for one of our testers on the Sandbox, and disappeared the next day.  My client and I are now concerned that this will become a problem when their ecommerce solution goes live.

 

Aside from asking customers to clear their browser cache, are there any steps we can take to fix or prevent this problem from occurring?

 

 

 

 

Hi jonathan2019

 

I can tell you that I use Accept on a regular basis for various testing and debugging purposes and have never seen this error occur, in any environment outside of 3rd party sites that had incorrectly implemented Accept.js and had saved and loaded the library locally. While I can't say with any certainty what happened in this isolated occurrence that you observed, I do know what causes it to occur and as a result I could only offer the known resolution. 

 

If you are able to reproduce it and provide the details you are welcome to open a support case from within the Merchant Interface in the Production account. In Sandbox you can email developer@authorize.net. Please make sure to mask any secure data within the repro details; such as CC#, Transaction Key. 

 

Regards, 

Elaine