If you're an online merchant or e-commerce provider by now you know you should use an iFrame based payment form to minimize your PCI compliance burden. And, in general, you're in luck! Since PCI DSS 3.0 is almost two years old by now, most payment gateways and payment processors have iFrame-based payment forms available for use. 

However, all is not rosy in the payment form landscape. Just because your gateway offers a payment form that has "iFrame" somewhere in the description does not mean it fulfills the spirit of the PCI guidelines, nor does it mean it's the right choice for your business. 

Because Spreedly integrates to over a hundred separate payment gateways, we see a lot of payment form implementations and can offer a unique perspective for online merchants choosing the right iFrame payment form.

Before we dive in, keep in mind this is mainly a cautionary tale meant to reinforce that you, the e-commerce merchant, are¬†responsible for choosing the tools that adhere to your stated level of PCI certification. Just because you use a gateway X, and that gateway X provides an iFrame payment form, doesn't mean your PCI assessor or the brands themselves will let you abdicate that decision. You're on the hook, so you need to be able to defend your position. Below we discuss¬†choosing an iFrame payment form across three different axes, starting with the most obvious ‚Äì adherence to the PCI specification.  

PCI Compliance

PCI compliance, which all online merchants must adhere and attest to, is a beast of certification. Vague guidelines, competing interpretations, and lots of misinformation make it¬†really hard to know what's required of your business. Fortunately, a series of updates to the original version 3.0 (now at 3.2) and some standalone guidance¬†provide¬†a much clearer picture of what types of iFrame payment forms let you self-attest using the SAQ A form (which is the least amount of PCI compliance burden you can assume). 

If this is already sounding like a lot of arcane terminology, I'd encourage you to read our guide:PCI DSS 3.0 for Online Merchants. We now know, unequivocally, that to qualify for SAQ A your iFrame payment form must ‚load all payment content from a PCI DSS compliant service provider‚Äù. This means the form fields that collect the credit card number and CVV, any accompanying javascript libraries, and the submission of the payment data itself, must both originate and return back to the payment provider itself. This might seem obvious, but in reality it's difficult to know if this is really what your provider is doing since there are often layers of abstraction between your use of the provider's client libraries and the actual representation in-browser.

We now know, unequivocally, that to qualify for SAQ A your iFrame payment form must load all payment content from a PCI DSS compliant service provider.

Here's an easy way to tell if your provider's iFrame form is adhering to this aspect of the PCI guidance.

  1. In your browser, navigate to a page that utilizes the provider's iFrame payment form (this could be a demo site, or a known customer).

2. Using your browser's developer tools, inspect the credit card number field.

3. In the rendered document view that comes up in your browsers' developer tools, look to see if the credit card number HTML form element (usually an input field) is rendered within an iFrame (e.g. there's an iFrame anywhere in its parent hierarchy). This is what it looks like when the field is not contained within an iFrame, meaning that sensitive field is not served directly from your provider and you are exposed to additional PCI compliance burden (taken from a production site using a popular gateway's payment form):

By contrast, this is what it looks like when a PCI-sensitive field like the credit card number is served directly from the payment provider within an iFrame:

This might seem like an arcane technical detail but don't dismiss it! It has a direct effect on your ability to self-assess using the 4 page SAQ A vs. the 40 page SAQ A-EP and it is your, not your payment gateways, responsibility to make the final PCI determination.  

Brand Continuity

Ugly, unusable, downright hostile payment forms are not only death to your conversion rate ‚ they also have a particularly insidious effect on your brand. Not a day goes by without someone taking to their preferred social media channel to vent about what great inconvenience your site has caused them. Do you want this kind of shame retweeted and liked over 2,000 times for your brand?

As an online merchant, store, or e-commerce¬†brand, it is your responsibility to craft the best experience for your users. Though this might take more time than just slapping your current payment provider's stock form on your site, the fact is that it's a commercially justified effort. Not only will your users have a delightful checkout experience, you will walk away with more $$ in your pocket from the non-trivial increase in checkout rates. Things to look for in an iFrame payment form are the ability to customize both the look and feel of the form as well as the structure of the form itself. This often manifests as the ability to position the credit card number and CVV fields independent of one another and set custom CSS properties on these fields, even though they live inside your provider's iFrame. While a more complex implementation for the merchant, this results in a better checkout rates for online¬†merchants and better brand experience for the customers.  


Old-school payment companies tend to be cut of a different cloth than modern technology or developer tooling companies. Large institutions can be secretive and protective of their technical documentation, which can meaningfully delay your integration effort. Thankfully, this divide is closing. But you should accept nothing less than publicly available integration guides, technical payments API documentation, and self-service test credentials. Having documentation is very different from having good documentation. Your provider‚Äôs developer documentation should be clearly organized both by purpose (mobile payments, etc‚Ķ) and product (iFrame form, etc‚Ķ). Additionally, the API documentation should be very clearly separated from the general guides. Guides are good for walking developers new to the toolset through the features and tend to be prose-oriented. API docs are good for when you know what you‚Äôre looking for and just need to see the raw technical details. These are two very different purposes best served by two different structures.  

iFrame Payment Form Comparisons

At Spreedly, it's our job to provide integrations to over a hundred payment gateways. As a result, we have a lot of relevant experience with iFrame payment forms. We have developed our own form as well. Let's look at how a few popular gateways' iFrame forms stack up by these characteristics:


If your payment gateway provides a really clean iFrame payment form that adheres to all the points raised here, then lucky you! However, chances are if you're using any but the top 3-5 developer-oriented gateways, your iFrame payment form options will be lacking. What to do in that case? Switching payment gateways is always an option, but many times there are business reasons to keep your existing processor. 

That's where Spreedly comes into play. Spreedly modernizes your antiquated gateway. Spreedly's tooling, built¬†by developers for developers as part of a modern payment stack, lets you integrate with the payment gateway of your choice. I hope this guide was helpful. Please sign up for a free developer account at Spreedly if you're not happy with your gateways' tooling. You can also view the Spreedly iFrame documentation if you want a point of comparison.

More from Our Blog

Recent Posts You Might Like

No items found.
See All Posts