PCI Compliance

PCI Compliance Best Practices - Making E-Commerce More Secure

Best practices for making e-commerce more secure while remaining PCI compliant.

Written by
Jenna Hutt and Justin Benson
Publication Date
July 8, 2020
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.

July 2020 Update:

The next version of the data security standard, PCI DSS 4.0, is in review and request for comment period with a release date expected in early 2021. In the meantime, 3.2.1 will remain valid for sometime yet.  

This is over four years from a major release of the DSS and will largely remain the same from the existing requirement standpoint, but additional requirements are expected to be added to to address new risks and threats as the payments landscape evolves and changes.

One of the primary goals of PCI DSS 4.0 is to promote security as a continuous process and add support and flexibility to achieve security. 4.0 is expected to allow organizations to demonstrate compliance in a variety of ways. We believe payments orchestration will continue to be a sound strategy for reducing scope and limiting ongoing maintenance costs.

Payments orchestration implementations that reduce the most amount of scope, (e.g.: iFrame and Express) keep the self-assessment questionnaire to the least effort — or the SAQ A.

The number one recommendation for payments participants is to reduce where payment data can be found.

More to come on PCI in 2021!

Original Blog Post (Feb 2017):

On February 2nd, 2017, the Payment Card Industry Security Standards Council (PCI SSC) updated its best practices guidelines for securing e-commerce and PCI compliance. Among other things, this is notable because PCI DSS 3.0 was released back in 2013 and a lot has changed since that time; most markedly the roll out of PCI 3.2 in April of 2016. 

Why the Confusion Between PCI SAQ A & A-EP?

Nearly all online merchants aim for a PCI SAQ A since it is the simplest, least time consuming PCI certification. Prior to PCI DSS 3.0, this was achieved via a UR Redirect to a hosted payment page, or a Direct Post or JavaScript library (the council sees both approaches as very similar). 

Most modern payment gateways, and therefore merchants, defaulted to a Direct Post or JavaScript approach vs. a URL Redirect, as customers preferred the extra control this gave them when it came to designing their payment page. In addition to creating the SAQ A-EP, however, PCI DSS 3.0 also stated that going forward the Direct Post is in greater scope and requires the much more arduous SAQ A-EP - part of the cause for confusion.

The iFrame Middle Ground

The second major impact of PCI DSS 3.0 was the somewhat quiet indication that the use of an iFrame approach allows a merchant to successfully qualify for a SAQ A (somewhat quiet because this information was released in a supplement published shortly after 3.0 came out). 

Proper use of an iFrame became a middle ground between a URL Redirect and a Direct Post approach.

At the time, Spreedly responded quickly to launch an iFrame. Our goal was to give customers as much design freedom as they had before with our Direct Post while ensuring our approach was secure and allowed certification under PCI SAQ A. We did a pretty good job, too, both in terms of speed to market and quality of offering. We have a group of customers today whose primary driver for using Spreedly is to use our iFrame with their legacy gateway, which either doesn't have an iFrame offering or does but our customer prefers our approach.

Providing PCI Compliance Clarification

The updated PCI SSC guidance is extremely helpful in clarifying the council's thinking around the different approaches online merchants take when it comes to integrating a payment page with their service provider. These approaches include a URL Redirect to a third-party hosted payment page, inline iFrame, embedded content in a merchant's page such as Direct Post or JavaScript-built forms, and directly against an API.

Below are a couple of key paragraphs from the guidance that will be of interest to our customers and other merchants.

Here's the key section as it relates to using an iFrame and qualifying for a PCI SAQ A:

At present, a merchant implementing an e-commerce solution that uses iFrames to load all payment content from a PCI DSS compliant service provider may be eligible to assess its PCI compliance using a reduced list of controls identified in SAQ A, the smallest possible subset of PCI DSS requirements, because most of the PCI DSS requirements are outsourced to the Payment Service Provider (PSP).

As it relates to the Direct Post/JavaScript approach, it looks like it puts online merchants in scope for the more arduous SAQ A-EP:

The merchant's payment form, loaded in the customer's browser, sends the cardholder data directly to the Payment Service Provider‚ not via the merchant's website or systems‚ ensuring cardholder data is not stored, processed, or transmitted via the merchant systems. However, the payment form is provided by the merchant; therefore the merchant' s systems are in scope for additional PCI DSS controls, which are necessary to protect the merchant website against malicious individuals changing the form and capturing cardholder data.

And further,

‚Merchants using a Direct Post e-commerce implementation may be eligible for PCI SAQ A-EP, providing they meet the eligibility criteria of that SAQ. Merchants should consult with their acquirer (merchant bank) or with the payment brands directly to determine whether they are required to validate their PCI compliance and which reporting method they should use. SAQ A-EP for PCI DSS v3.2 currently includes 191 requirements.

When discussing JavaScript, the analysis is similar to Direct Post:

As the merchant controls the manner in which cardholder data is collected and transmitted to the Payment Service Provider, the same PCI DSS controls apply as with the Direct Post Method described above (Section 2.3).

Helpful Guidance

The introduction of PCI 3.0 created some confusion around the best methods for creating a secure e-commerce environment and their PCI compliance impact. Our conclusion is this guidance release is helpful in giving straightforward descriptions of the major different approaches to building a secure payment solution.

The difference in amount of work between the PCI SAQ A and the SAQ A-EP is significant. For merchants that want to avoid the more arduous requirements of SAQ A-EP, there are benefits to using an iFrame over the Direct Post or Javascript methods. And based on feedback from Spreedly customers who use our iFrame, namely the ease and flexibility with which it allows them to customize their payment page, we don't see the benefit in using a Direct Post or Javascript method over the iFrame.

For more information on our iFrame solution check out the this blog post.

Related Articles

PCI Compliance

Outsmarting Data Breaches: What is PCI Compliance & Why is it Important?

The importance of PCI compliance and how Spreedly can assist in ensuring your business is always up to date on the latest PCI standards

Posted on Oct 12, 2022 by Jordan Chavis & Deborah Boyland

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