6

A common feature I see in a lot of small business ecommerce websites is that when I click on the CHECKOUT button, I am taken away from the website and redirected to the url of a 3rd party payment gateway like paypal, authorize.net etc... After I make my payment on this 3rd party site, I am redirected back to the small business ecommerce website.

I would like to simplify this process for a few clients of mine. I plan to make a payment form that others can embed into their website via an iframe. The payment form will be behind an SSL. When my payment form receives information, I will pass it along to a merchant gateway like paypal, and reload the iframe with the success/fail response.

Are there any major issues to this iframe approach? I ask because I don't recall payment gateways like paypal offering iframe embed codes for their payment pages, even though it seems a trivial thing to offer. If they can offer a checkout url to website owners to embed into their page, they should just as easily be able to offer an iframe embed code.

John
  • 32,403
  • 80
  • 251
  • 422
  • Voting to close as this is more something for the security dept of Stack Exchange... – Maarten Bodewes Oct 30 '12 at 20:13
  • The problem is this is the method used by hackers to intercept the details entered and steal them so nobody would trust your site. That's why merchants direct link to the payment processor and re-direct back. – Chris Latta Oct 30 '12 at 22:47

2 Answers2

5

A fundamental aspect of the security of an HTTPS connection is the verification of the identity of the remote party. It's one thing to exchange data secretly with someone, but you need to know with whom.

From a technical point of view, the server's identity is verified using its certificate:

  • It needs to be trusted, i.e. the client can verified it was issued by an authority it trusts (RFC 3280/5280).
  • It needs to be issued to the entity the client wants to talk to, i.e. the host name needs to be verified (RFC 2818, Section 3.1).

However, the technical aspect is only part of the solution. The user needs to be able to see which site the browser is trying to connect to. This is a user interface problem, and only the user can check what the browser is trying to do, within reason of what its UI is displaying (it's unrealistic to expect most users to use developer tools).

Using an iframe hides the name of the site to which the user is actually connected for that iframe (only the address of the main page is displayed in the address bar). This prevents the user making this verification.

In addition, it would be even worse if the HTTPS iframe was within an HTTP page, in which case the user couldn't even check that HTTPS is used at all.

There are bad example of embedded iframes, in particular 3-D Secure, because (a) it recommends using an iframe and (b) even if an iframe wasn't used, the name generally has nothing to do with the user's bank, the merchant site or the credit card company.

Bruno
  • 119,590
  • 31
  • 270
  • 376
1

One potential problem (that I actually ran into, as a user) is that the hosting page probably won't be using SSL and have the little "tells" that people are told to look for in articles about being a savvy Internet shopper. There'd be potential for losing sales at the last possible minute due to user caution.

There are also potential issues with cross-domain scripting. That's a huge topic, and doing it even when you want it to be possible can be very very challenging, but it's not impossible, so there's some potential for abuse there.

Ann L.
  • 13,760
  • 5
  • 35
  • 66