PCI Compliance

Choosing the Right iFrame Payment Form

Using an iFrame payment form to minimize PCI compliance burden

Written by
Luke Evans
Publication Date
June 9, 2022
Social Share
Don’t miss our latest news and updates
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

If you're an online merchant or e-commerce provider, you likely already know you should use an iFrame-based payment form to minimize your PCI compliance burden. Most payment gateways and payment processors have iFrame-based payment forms. However, all is not as it appears in the payment form landscape. Simply because your gateway offers a payment form with "iFrame" in the description does not necessarily mean it meets the requirements to be considered PCI compliant, and therefore it may not be the right choice for your business. 

Spreedly integrates with over a hundred separate payment gateways supporting a wide variety of payment form implementations. This provides our customers with a unique perspective for online merchants choosing the right iFrame payment form.

One important point to keep in mind is that you, the eCommerce merchant, are responsible for choosing the tools that support your stated level of PCI certification. For example, just because you use a given gateway, and that gateway provides an iFrame payment form, does not mean your PCI assessor or the card associations themselves will let you abdicate that decision. Your company could be liable, so you need to ensure your compliance. Below we outline how to evaluate an iFrame payment form across three different vantage points, starting with the most obvious – adherence to PCI specifications.

PCI Compliance

All online merchants must adhere and attest to being PCI compliant. Meeting PCI regulations can be expensive and time-consuming due to vague guidelines, competing interpretations, and many conflicting sources of information. This can make it extremely difficult to know what's required of your business. Fortunately, some resources 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). 

(One helpful article of note is our blog: PCI DSS 3.0 for Online Merchants.)

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 PCI compliant service provider. Although this might seem obvious, in reality it's difficult to know if this is truly what your provider is adhering to since there are often layers of abstraction between your use of the provider's client libraries and the actual representation in-browser.

Here's an easy way to check if your provider's iFrame form is PCI Compliant:

  • 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).
  • Using your browser's developer tools, inspect the credit card number field.
  • In the rendered document view, 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 such as the credit card number is served directly from the payment provider within an iFrame:

This might seem like a technical detail but it’s important! It has a direct effect on your ability to self-assess using the four-page SAQ A vs. the 40-page SAQ A-EP and it is your organization’s responsibility to make the final PCI determination.

Brand Continuity

Poorly designed payment forms are not only harmful to your conversion rate, they also can have an insidious effect on your brand.

As an online business, it is your responsibility to craft the best experience for your users. This means there is a level of effort beyond simply adding your current payment provider's stock form to your site. When done correctly, your customers will have a friction-free checkout experience that ultimately produces more revenue from an increase in conversion rates.

It is advisable to look for a solution that allows you to customize 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, this results in better conversion rates for online merchants and a better brand experience for your customer.


Legacy payment companies tend to be cut of a different cloth than companies that were created to facilitate online transactions. Some providers can be protective of their technical documentation, which can add a 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/developer documentation should be clearly organized by purpose (mobile payments, etc‚) and product (iFrame form, etc). Additionally, the API documentation should be 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 are looking for and only need to see the raw technical details. These are two very different purposes, best served by two different structures.

Spreedly provides integrations to over 120 payment gateways. This has given us experience with a wide variety of iFrame payment forms. We have developed our own form as well.


Ideally, your payment gateway should provide a clean iFrame payment form that adheres to all the points raised in this article. However, your iFrame payment form options could be lacking. Switching payment gateways is always an option, but many times there are business reasons to keep your existing processor. 

That's where Payments Orchestration comes into play. Spreedly can help modernize your payments process. Spreedly's platform, built with the payments developer in mind and as part of a modern payment stack, lets you integrate with virtually any payment service provider.

To learn more, please sign up for a free trial account at Spreedly. You can also view the Spreedly iFrame documentation for more information.

Related Articles

PCI Compliance

Choosing the Right iFrame Payment Form

Using an iFrame payment form to minimize PCI compliance burden

Posted on Jun 09, 2022 by Luke Evans

PCI Compliance

Spreedly Solutions Stack: Comply with Regulations

Manage payment regulations while minimizing regulatory burden and reclaiming valuable time with Spreedly.

Posted on Jun 03, 2022 by Peter Mollins

PCI Compliance

SOC 2 Type 2 Certification Update

Spreedly has updated its SOC 2 Type 2 credentials, affirming our strong commitment to cybersecurity for all payments stakeholders.

Posted on May 13, 2022 by Rachel Fine