cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

AUthorize.net hosted payment page not working in Chrome Version 60

We are getting this error

on the click of submit on the hosted payment form.

 

Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://xxxx.xxx.com') does not match the recipient window's origin ('null').


I read some documentation in internet and noted the problem there mentioned as well . Adding for reference
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/fsDaKFqvU20


The hosted payment iframe failing Chrome60 , but is working in other browsers (namely Firefox/IE)

 

Please advise ,

debasishbose2k
Contributor
2 ACCEPTED SOLUTIONS

Accepted Solutions

Hi @Aaron,

 

It's true, this is a valid issue with the newest versions of Chrome. 

 

The X-Frame-Options directives are deprecated, the modern alternative is the Content-Security-Policy header, which along with many other policies can white-list what URLs are allowed to host your page in a frame, using the frame-ancestors directive, frame-ancestors supports multiple domains and even wildcards.

 

One way to resolve this issue on Apache is to use the following in your .htaccess file.

Header set Content-Security-Policy "frame-ancestors 'self' *.YOUR_WEBSITE.com *.authorize.net"

Or for a specific file: 

<Files iCommunicator.html>
Header set Content-Security-Policy "frame-ancestors 'self' *.YOUR_WEBSITE.com *.authorize.net"
</Files>

See a working example at : https://nexwebhost.com/authorizenet/gethosted.html

Powered by NexWebSites.com -
Certified Authorize.net developers

View solution in original post

NexusSoftware
Trusted Contributor

Hi 

 

I would like to confirm that the Hosted payment page did work in our environments once we added the Content Security Policy Header in the request .  THe x-frame header request seems to be deprecated by Chrome in Version 60(as suggested by other developers) , and eventually be for other modern browsers. We changed our setting to add the new Attribute in header and that helped it to work seamlessly. 

 

Thanks and regards 

 

Debasish

View solution in original post

19 REPLIES 19

Check out https://nexwebsites.com/authorizenet/ with your version of Chrome, as I am now with Chrome Version 60.0.3112.90. If you get no error message, it's your implementation.

Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

Hi @debasishbose2k,

 

Even if this ends up being something on your side, please share details with us here. I'd like to be able to prevent anyone else from running into whatever problem you've run into.

 

  • How are you calling the payment form, by redirecting the browser or embedding into an iframe?
  • Are you posting an iFrameCommunicator URL in your token request?
  • Anywhere we can see the code or see the website in action?

I seem to have hit the same problem.  In my case, the payment form is embedded in an iframe and I am sending an iFrameCommunicator URL in the token request.

 

The payment form would work in Firefox (54.0.1), but not in Chrome (60.0.3112.90).  In the Chrome console, the following error would display when the payment form loaded into the iframe:

 

Refused to display 'https://xxxxxx/system/payment/iframecommunicator.html?procData=xxxxxxxxxxxxxxxxx#action=resizeWindow&width=935&height=864' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

 

The web server was sending the header:

 

X-Frame-Options: SAMEORIGIN

 

when the iframe communicator page was sent back.  Elliminating that header for the iframe communicator response does allow the form to post the result of the charge back to the application.

I can confirm, same error in Chrome 60.

 

Here is the link to the google page that explains that change (and confirms that it was released in Chrome 60)

 

https://www.chromestatus.com/feature/4678102647046144

 

Trying a Content-Security-Policy header to fix it.  Will report back with results.

 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors

Unfortunately the X-Frame-Options: sameorigin header seems to win over a Content-Secuirty-Policy: frame-ancestors right now, so I am forced to remove the X-Frame-Options header and add a CSP header event though it only works for some web browers.

These are the answers

 

We are embedding the payment form in an iframe

We pass the irame url in the token request

YEs , I can schedule a webex (today 3-6 PM PST) or Friday (9-6 pm PST)

Hi @debasishbose2k,

 

Thanks for the response and the offer to conference about this. I apologize, but I'll actually be out of the office until Monday. If we haven't come up with good ways to duplicate this or reliable recommendations of how to avoid this by then, I'll definitely want to get together with you next week.

Hi @Aaron,

 

It's true, this is a valid issue with the newest versions of Chrome. 

 

The X-Frame-Options directives are deprecated, the modern alternative is the Content-Security-Policy header, which along with many other policies can white-list what URLs are allowed to host your page in a frame, using the frame-ancestors directive, frame-ancestors supports multiple domains and even wildcards.

 

One way to resolve this issue on Apache is to use the following in your .htaccess file.

Header set Content-Security-Policy "frame-ancestors 'self' *.YOUR_WEBSITE.com *.authorize.net"

Or for a specific file: 

<Files iCommunicator.html>
Header set Content-Security-Policy "frame-ancestors 'self' *.YOUR_WEBSITE.com *.authorize.net"
</Files>

See a working example at : https://nexwebhost.com/authorizenet/gethosted.html

Powered by NexWebSites.com -
Certified Authorize.net developers
NexusSoftware
Trusted Contributor

Hi 

 

I would like to confirm that the Hosted payment page did work in our environments once we added the Content Security Policy Header in the request .  THe x-frame header request seems to be deprecated by Chrome in Version 60(as suggested by other developers) , and eventually be for other modern browsers. We changed our setting to add the new Attribute in header and that helped it to work seamlessly. 

 

Thanks and regards 

 

Debasish