cancel
Showing results for 
Search instead for 
Did you mean: 

SIM iFrame SAMEORIGIN issue

Hi All,

 

I originally posted this as a reply under another topic, but the issue is urgent, and I want others to find this easily in the future.

 

We fully implemented the Iframe approach using the sandbox gateway, only to discover the production gateway is giving us a sameorigin denial.

 

Our setup is:

- SSL protected site;

- iFrame loading Hosted Payment Form from a form post.

 

When posting to auth.net the form never loads and we get the following in the browser console:

 

"Refused to display 'https://secure2.authorize.net/gateway/transact.dll' in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN'."

 

Is anyone else seeing this issue? I assume this is something Auth.net needs to fix.

 

I would love some weigh-in on this issue.

 

Thanks all!

 

- Charles

cfahey
Member
1 ACCEPTED SOLUTION

Accepted Solutions

Hello @cfahey

 

We don't recommended using a hosted payment form within an iFrame and are unlikely to make changes if it breaks in production.  

 

UPDATE: However, if you have Visa Checkout enabled for your production account, it enforces SAMEORIGIN.  Disabling Visa Checkout may help resolve this for you.

 

Richard

View solution in original post

8 REPLIES 8
RichardH
Administrator Administrator
Administrator

Hi @RichardH,

 

Thanks for the link.

 

However it only confirms that this is an issue on the Auth.net server.

 

Can you tell me how to get Auth.net to disable the same-origin header (or get my site set in a ALLOW-FROM header), since it improperly prevents placing the payment form inside an iframe? 

 

Again, this worked successfully in the sandbox, and there is no documentation that says it is not permitted.

Why don't your switch it to DPM, then you can do whatever you need? DPM and SIM are also the same.

read the DPM section in the SIM doc

http://www.authorize.net/content/dam/authorize/documents/SIM_guide.pdf

Hi @RaynorC1emen7,

 

While a fine idea, my understanding is that DPM requires the merchant to collect the CC info before posting to the gateway.

 

This means our site would be handling the CC info, which is something we don't want to do, for PCI compliance reasons.

 

But more importantly, using the SIM in an iFrame works properly in sandbox, and there's no documentation that says it isn't allowed. This seems to be a bug on Auth.net's part that I, and I would think most developers, need fixed.

 

Is there anyone from Auth.net who can weigh-in with a deifnitve answer?

 

Are there any developers out there successfully using SIM inside an iFrame?

 

Thanks all !

Hello @cfahey

 

We don't recommended using a hosted payment form within an iFrame and are unlikely to make changes if it breaks in production.  

 

UPDATE: However, if you have Visa Checkout enabled for your production account, it enforces SAMEORIGIN.  Disabling Visa Checkout may help resolve this for you.

 

Richard

Hi @RichardH,

 

The VISA Checkout was indeed the cause!

 

Thanks for finding us a solution!

 

All the best!

 

- Charles

For clarification, does this mean it is NOT possible to use the hosted payment form within an iframe while Visa Checkout is enabled in the account?

 

I am currently working on a setup that would use the hosted-and-framed payment form for direct payments with the possibility of adding Visa Checkout as a completely separate and non-framed option (not on the hosted payment form) in the near future.

 

Is it possible to enable Visa Checkout in the account but specifically disable it on the hosted payment form?

 

Fritz

coppercup
Regular Contributor

@coppercup 

 

A present, the account setting for Visa Checkout determines if it's presented on the hosted payment form and require SAMEORIGEN.  It's not currently possible to decouple the two.  

 

You are welcome to post this as a new feature using our Ideas forum. This will allow others to vote on and make suggestions to improve the request.

Richard