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?
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
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).
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.
‚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.
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).
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.
For more information on our iFrame solution check out the this blog post.