Accept.js - Sandbox: Library is not coming from Accept server

[jrm89]

Today I attempted to deploy me application to a DEV server and I started getting the following error:  Library is not coming from Accept server--- a7e38542d3a404b4b3ac37a7252bca2e7f3dd724a357aa93ce22f413e74333c3

Here is the script I'm including:

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

It works fine if you do the production url (js.authorize.net), but it stopped working for me today when using the sandbox url.  I don't know what is happening.  To cut down on all variables, I literally created a blank html document with this script tag in the header and I still get the error message in the console.  It happens in chrome, firefox, and edge.  I've been testing successfully the last several days with no issues.  I'm stumped at the moment.  Anyone run across this?

[jasonb]

I'm seeing the exact same issue. Using jstest.authorize.net leads to "Library is not coming from Accept server" error in Accept.js when loading AcceptCore.js from  jstest.authorize.net.  FireFox, Safari, Chrome.  Plugins disabled. 

[cmchristensen]

I am seeing the issue as well. We discovered after updating to Chome version 78 (and clearing cache) today - Firefox 70 seems to have the same problem as well.

Chrome 77 gives this warning:
A cookie associated with a cross-site resource at http://authorize.net/ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

Perhaps this warning will give insight?

[dliv-gw]

We are having the same problem:

- starting today

- in the sandbox

- using the hosted form variant (AcceptUI.js)

This can be easily reproduced by:

- take the code sample at: https://developer.authorize.net/api/reference/features/acceptjs.html#Example_of_the_Complete_HTML_Pa...

- ensure you're using the "Hosted Form" sample

- update with your apiLoginID and clientKey

- serve the page with a static file server

- see console warning: Library is not coming from Accept server---a7e38542d3a404b4b3ac37a7252bca2e7f3dd724a357aa93ce22f413e74333c3

- add a card

- see console error: E_WC_03: Accept.js is not loaded correctly

In our testing, the error appears to be specific to AcceptUI.js and not the Accept.js library version ("Your Own Payment Form"). If it is a CDN / caching issue, this could vary...

This appears to relate to past issues:

- https://community.developer.authorize.net/t5/Integration-and-Testing/E-WC-03-Accept-js-is-not-loaded...

- https://community.developer.authorize.net/t5/Integration-and-Testing/Library-is-not-coming-from-Acce...

[cmchristensen]

We are seeing the issue with both AcceptUI.js (hosted payment form), as well ass the Accept.js (own payment form) libraries.

[Fallenstedt]

We have noticed there is a potential issue between

• https://js.authorize.net/v1/Accept.js (Production)
  
• https://jstest.authorize.net/v1/Accept.js (Sandbox)
  

We noticed that both expected hashes are identical on both scripts. Upon hashing the Production AcceptCore.js, we noticed it matched the Sandbox and Production Accept.js expected hash of (79ec52f0ce86fb27c47d1f860ba62d34ad5fe6cd3778ee0952ac698f52096e81). 

Upon hashing the Sandbox AcceptCore.js, we noticed it did not match either with a result hash of (a7e38542d3a404b4b3ac37a7252bca2e7f3dd724a357aa93ce22f413e74333c3). 

Is there a possibility the Sandbox Accept.js is using the Production copy instead of the Sandbox copy?

Hopefully someone from Authroize.net can confirm this soon.

[Fallenstedt]

You can reproduce this via bash:

curl https://js.authorize.net/v1/Accept.js -H 'Cache-Control: no-cache'
curl https://jstest.authorize.net/v1/Accept.js -H 'Cache-Control: no-cache'

curl https://js.authorize.net/v1/AcceptCore.js -H 'Cache-Control: no-cache' -o output.txt
curl https://jstest.authorize.net/v1/AcceptCore.js -H 'Cache-Control: no-cache' -o test_output.txt
shasum -a 256 output.txt
shasum -a 256 test_output.txt

[AdamT]

We believe that was have identified and resolve the cause of this issue. Can you please try again?

Thank you.

-Adam

[Fiala1904]

It still is not working for me.

[litza]

What a relief to discover this thread - we've been having the same experience during the past few days on our development server. Unfortunately it's still not working for us this morning.