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