0

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?

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

1 Answer 1

Reset to default
1

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.

Improve this answer
2
  • PCI promotes a method that is inferior in terms of security to a redirect? Wow.
    – user2530062
    Jun 16, 2021 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, 2021 at 7:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .