Sandbox Accept Hosted CSP issue

[cc-45335]

Greetings!

We use the Accept Hosted API for our C# based payment forms. Production is working fine. However, our testing forms suddenly appear to have stopped working when testing payments. I'm seeing the following in the console:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' blob: https://*.ads-twitter.com https://*.authorize.net https://*.bing.com https://*.ceros.com https://*.contentsquare.com https://*.contentsquare.net https://*.cookiereports.com https://*.doubleclick.net https://*.eloqua.com https://*.en25.com https://*.facebook.net https://*.google-analytics.com https://*.google.com https://*.googleadservices.com https://*.googletagmanager.com https://*.gstatic.com https://*.idio.episerver.net https://*.licdn.com https://*.linkedin.com https://*.optimizely.com https://*.twitter.com https://*.visa.com https://*.youtube.com https://api.company-target.com https://cdn-assets-prod.s3.amazonaws.com https://code.jquery.com https://company-target.com https://id.rlcdn.com https://optimizely.s3.amazonaws.com https://rlcdn.com https://s.company-target.com https://scripts.demandbase.com https://segments.company-target.com https://tag-logger.demandbase.com https://tag.demandbase.com". Either the 'unsafe-inline' keyword, a hash ('sha256-rQFcSQ+uPvBBS36Ebz2AA8DWF5LxdwuQKeLhxEfN+Ec='), or a nonce ('nonce-...') is required to enable inline execution.

And

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' https://*.authorize.net https://*.ceros.com https://*.eloqua.com https://*.google.com https://*.gstatic.com https://*.licdn.com https://*.optimizely.com https://*.visa.com https://fonts.googleapis.com". Either the 'unsafe-inline' keyword, a hash ('sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

I just noticed this issue on Friday. All of our test forms that were working previously in the last month seem to be having this issue (pointing to https://test.authorize.net/payment/payment). Our production forms that point to https://accept.authorize.net/payment/payment  work fine. It doesn't look like they are applying a CSP to the production environment.

If I go straight to https://test.authorize.net/payment/payment the same errors appear in the console there. Is authorize.net blocking their own script/styles via the CSP in the test sandbox? Is anyone else seeing this?

Thanks

[aleksandarilic]

Did somebody solved this issue?

[khurram2875]

I am also having the same issue https://test.authorize.net/payment/payment?token={token} did not work for me either

[evaelfie]

---

@cc-45335 wrote:

Greetings!

We use the Accept Hosted API for our C# based payment forms. Production is working fine. However, our testing forms suddenly appear to have stopped working when testing payments. I'm seeing the following in the console:

Refused to execute inline script because it violates the following Content Security Policy directive: "script-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' blob: https://*.ads-twitter.com https://*.authorize.net https://*.bing.com https://*.ceros.com https://*.contentsquare.com https://*.contentsquare.net https://*.cookiereports.com https://*.doubleclick.net https://*.eloqua.com https://*.en25.com https://*.facebook.net https://*.google-analytics.com https://*.google.com https://*.googleadservices.com https://*.googletagmanager.com https://*.gstatic.com https://*.idio.episerver.net https://*.licdn.com https://*.linkedin.com https://*.optimizely.com https://*.twitter.com https://*.visa.com https://*.youtube.com :https://api.company-target.com https://cdn-assets-prod.s3.amazonaws.com https://code.jquery.com https://company-target.com https://id.rlcdn.com https://optimizely.s3.amazonaws.com https://rlcdn.com https://s.company-target.com https://scripts.demandbase.com https://segments.company-target.com https://tag-logger.demandbase.com https://tag.demandbase.com". Either the 'unsafe-inline' keyword, a hash ('sha256-rQFcSQ+uPvBBS36Ebz2AA8DWF5LxdwuQKeLhxEfN+Ec='), or a nonce ('nonce-...') is required to enable inline execution.

And

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-9ildXBnHfUmPXCIYGXW6sA==' https://*.authorize.net https://*.ceros.com https://*.eloqua.com https://*.google.com https://*.gstatic.com https://*.licdn.com https://*.optimizely.com https://*.visa.com :https://fonts.googleapis.com". Either the 'unsafe-inline' keyword, a hash ('sha256-0EZqoz+oBhx7gF4nvY2bSqoGyy4zLjNF+SDQXGp/ZrY='), or a nonce ('nonce-...') is required to enable inline execution. Note that hashes do not apply to event handlers, style attributes and javascript: navigations unless the 'unsafe-hashes' keyword is present.

I just noticed this issue on Friday. All of our test forms that were working previously in the last month seem to be having this issue (pointing to :https://test.authorize.net/payment/payment). Our production forms that point to https://accept.authorize.net/payment/payment  work fine. It doesn't look like they are applying a CSP to the production environment.

If I go straight to :https://test.authorize.net/payment/payment the same errors appear in the console there. Is authorize.net blocking their own script/styles via the CSP in the test sandbox? Is anyone else seeing this?

Thanks

---

It appears that Authorize.Net has recently updated the Content Security Policy (CSP) on their sandbox environment to be significantly stricter. As you've observed, the CSP is now blocking inline scripts and styles unless they are accompanied by an appropriate nonce, hash, or the use of unsafe-inline which is generally discouraged for security reasons. This is why your test forms are now failing while your production forms , which still allow inline scripts/styles, continue to work as expected.

[magistvupdate_u]

It’s interesting to see how recent CSP tightening on the Authorize.Net sandbox is affecting multiple developers. These kinds of changes often highlight how critical it is to test integrations under evolving security conditions. For anyone who works with API-based services or payment gateways across different environments, keeping your testing infrastructure flexible is essential.

I recently had a similar experience while testing a media-based API setup through Magis TV free for Firestick, where sandbox policies impacted embedded scripts. It reminded me how even minor CSP or header updates can disrupt functionality until reconfigured. Hopefully Authorize. Net rolls out clearer guidance for developers soon.