PCI Compliance Best Practices – Making E-Commerce More Secure

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.

The release of PCI 3.0 introduced the SAQ A-EP – a roughly 40 page requirement compared to the much briefer 4 page SAQ A. This created a great deal of concern and a lot of open questions as to exactly what qualified for a SAQ A vs. A-EP. The PCI SSC update appears aimed, in part, at clearing up this confusion.

pci compliance best practices

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 URL 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 a secure iFrame solution. 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).”

You can download the report here to read the source and capture all of the detailed commentary on the various different methods.

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 documentation. And you can get access to our API here.

 

Build PCI compliant web and mobile services that easily integrate to your preferred processing partners for seamless transacting.

Create a dev account