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

[debasishbose2k]

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 ,

[NexusSoftware]

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.

[Aaron]

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?

[rcourtois]

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.

[wundbread]

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

[wundbread]

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.

[debasishbose2k]

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)

[Aaron]

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.

[NexusSoftware · Accepted solution]

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

[debasishbose2k · Accepted solution]

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