I'm building a checkout page for a website and have a checkout page with a content security policy (CSP). When the customer pays with a card, they will see a box popup with the bank page that allows the bank to verify (if they want).

The problem I have is that the box that pops up is an iframe and I don't really want to allow all for frame-src in my CSP, I've currently allowed www.securesuite.co.uk but I'm guessing that's not the domain a German or French bank will use? Also I have a MasterCard but not a Visa or Maestro card and I don't have accounts for all the major banks they may all use different providers. My bank, Metrobank uses something like www.securesuite.co.uk/metrobank/ other banks do something similar according to Google.

Eventually, my CSP reporting page would gather them all but each one would mean a failed transaction for each failing frame source.

Do all banks use www.securesuite.co.uk? Does anybody else have a list of the domain names that are used by 3D secure across different banks and card types? We are based in UK/Europe and customers are spread across Europe and will use cards from all sorts of banks.

1 Answer 1


Appreciate this is an older question, but i recently came across the same issue looking after a fortune 50 e-commerce site and thought i'd share my thoughts.

Unfortunately, the new 3DS2 implementation is iframe based, and not really compatible with CSP. Most banks in the World will present a different domain for its iframe content, and it's absolutely not possible to determine and maintain a full list of them all. With all the will in the World, it's unfortunately true that you will be losing sales.

The best thing to do is really to just allow frame-src * on the final checkout page, and only that page, if you can. This might seem a lax approach, but when you realise that the payment page is critical to the security of your site, you actually gain the opportunity to remove some of the non-essential hosts from the checkout page by having a 'lite' CSP for that page. So it's not all doom and gloom. The only other option is to have a separate domain for your checkout, which i have seen some sites do. Although the seamless handover of your session state from these different domains is going to introduce more security problems than it solves.

I've explored many other options too... like using a new window/tab, or full redirect for the iframe URL... but we did some testing and confirmed that (for us) there would be a noticeable drop-off in successful payments. I suspect any business would feel a similar hit.

There are some other edge-case issues with CSP/browser-sec on a checkout page. For example, some bank's iframes try to open a URI like examplebank://open in the hope of handing over to a mobile/native app. If the CSP blocks that, it also sometimes affects any fallback logic. And other banks, bizarrely, present the 'x-frame-options: deny' header on the iframe content, wanting to be full-paged, and will never properly work.

3DS maturity is still super hit-and-miss at the moment depending on the bank, and i would do the best you can without risking your bottom line.

  • 1
    Thank you, I ended up doing that and softening the CSP for the checkout page. It just feels like thats where you should be most strict, but it just isn't practical. Its good to hear someone else had come to the same conclusion. I want to avoid something like the issue British Airways had with dodgy code on checkout. I thought when I asked this that I was missing something obvious. Jan 19, 2021 at 16:36
  • Couldn't the payment provider handle this inside their iframe - instead of redirecting their iframe?
    – enspandi
    Feb 9, 2021 at 17:16
  • @enspandi not really... because the payment provider shouldn't be able to see the data from the bank, so they can only take the challenge URL from a bank and throw it into an iframe. Some banks do seem to use 3rd party companies to provide their 3ds content... so you can have several banks using a similar/same domain for iframe content. But this isn't a standard, and i'm not sure why a bank would choose to do this as it seems a less secure approach. I guess 'its easier' is the answer. Good comment though.
    – hiburn8
    Feb 9, 2021 at 23:36

You must log in to answer this question.

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