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.
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.
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).
You can download the report here to read the source and capture all of the detailed commentary on the various different methods.