Let's take some examples:

  1. Pay Pal, Apple Pay (examples via Saferpay) - will not load in an iFrame
  2. Visa Checkout, Stripe (example), Saferpay (link above) - credit card data can be input in an iFrame

Is there any technical/security reason why payment service providers differ in their approach to restricting iframe usage for credentials/payment information input? Or this is simply difference in risk management (and its supporting technologies for fraud prevention), business decision or maybe a legacy (and non-secure) integration architecture?

  • The company I work for supports paypal, applepay, googlepay, etc from within an iframe. It just takes more work. – Bobson Jun 15 at 4:56

One contributing factor may be that PCI SSC rewards use of iframes by granting SAQ A status to merchants who use it, lowering the number of audit requirements down to a bare minimum. That would explain why you see it more commonly with credit cards, although as @Bobson pointed out many alternative payments also support iframes.

  • PCI promotes a method that is inferior in terms of security to a redirect? Wow. – user2530062 Jun 16 at 5:58
  • 1
    @user2530062 - No, it says it's equally secure (they're both SAQ A). In both cases, the merchant's website is providing a URL to the browser, and the browser loads the payment page from - and submits it back to - the card processor's website. Whether it's all contained inside a self-contained iframe or whether it redirects the parent page doesn't change that. – Bobson Jun 16 at 7:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.