PCI-DSS For Online Merchants

PCI-DSS (Payment Card Industry - Data Security Standard) was invented because of the data breaches. Data breach is one of the channels where fraudsters get hold of cardholder data, such as card numbers, expiration dates, billing information, and sometimes CVV. These data can be used to attempt unauthorized payments. The breach risk is not only with online merchants, in-store offline payments traditionally have stored cardholder data in their computer systems such as in POS databases.

Introduction of PCI-DSS

PCI-DSS is a set of 12 requirements to guide and enforce parties involved in payments to safe-guard the cardholder data. All parties report their compliance to card network (Visa, MasterCard, AMEX, etc.) on regular basis (for merchants, it's annual). PCI-DSS applies to both online and offline card payments. The standard applies to all parties, not just merchants, but payment service providers as well. These 12 requirements cover not only technologies, but policies, processes, and procedures.

A glimpse of the 12 requirements on their subject lines:

1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks 
5. Use and regularly update anti-virus software or programs
6. Develop and maintain secure systems and applications
7. Restrict access to cardholder data by business need to know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information security for all personnel

These 12 requirements expanded in details are vast, complex, and tedious. For example, Self Assessment Questionnaire (SAQ) - D for merchants is a 79-page form to fill out. However, businesses that take payments are dramatically diverse and different in their payment volumes, operating models, integration methods with payment service providers, and deployment infrastructure. All these aspects directly influence the security risks of a merchant. Therefore, PCI-DSS council tries to make it simpler for simpler merchants.

PCI-DSS distinguish merchant levels by number of transactions, and then the requirements to meet compliance are different.

For PCI-DSS Level 1 merchants, compliance must be conducted or audited by a Qualified Security Assessor (QSA). In order words, it needs to have a third party professional to bless the compliance. Again, because of the payment volume, these are the most risky merchants - if data breach happened to them, millions of cardholders' data are at stake. So they deserve professional certification of their security measures.

For levels 2 to 4, Self Assessment Questionnaire (SAQ) can be used together with quarterly network security scans done by an Approved Scan Vendor (ASV).

PCI-DSS, though establishes good guidelines in general data protection, doesn't care much about general data breach. It specifically cares about data breaches of cardholder data, such as card numbers, expiration dates, etc.

Now, "Scope" is the magic word in PCI-DSS. If you can prove that a critical concerning area by PCI-DSS is out of scope in your implementation, in other words, there are no cardholder data involved in an area, then data breach in that area is irrelevant to PCI-DSS. For example, if your web site, even though it's taking payments, doesn't get to see or touch the card number entry by your users, then your web site, in terms of cardholder data, is out of scope.

Therefore, there are 8 different SAQ forms based on types of merchants and how payment acceptances are implemented.

PCI-DSS SAQs Relevant to Online Merchants

For online merchants specifically, the relevant SAQs are:

As we can see, SAQ-A is the simplest form and only 5 out of 12 requirements are in scope for merchants; the rest of the compliance is outsourced to payment service provider who is PCI-DSS compliant.

Scenarios of Integration and Their PCI-DSS Requirements

Now let's look at some example integration scenarios and see which SAQ apply.

Server Side Integration with Payment Service Provider Only

Merchant's web page collects cardholder data, passes them to merchant's server; merchant's server then invokes payment service provider's authorize API using the collected cardholder data.

This is SAQ-D Merchant, because merchant's system (web site and server) collects and transmits cardholder data.

Merchant Client Encrypts Data, plus Server Side Integration

A variation of the above scenario: merchant's web site encrypts the collected cardholder data which can only be decrypted by payment service provider, passes the cipher to merchant's server; merchant's server invokes API with cipher.

This is still SAQ-D Merchant, because merchant's web site collects cardholder data, regardless whether it encrypts the data in transmit. Think about it this way: if merchant's web site is compromised, malicious actor can inject program to capture plaintext data before encryption.

Merchant Redirects Cardholder to Service Provider's Web Site to Transact

Merchant redirects cardholder to payment service provider's web site, where payment service provider shows content completely originated from themselves to collect and process cardholder data; at the end of payment, service provider redirects cardholder back to merchant's web site to show non-card data information.

This is SAQ-A, because merchant is not in the loop at all when cardholder data is collected or processed.

Merchant Redirects Cardholder to Service Provider's Web Site which is customized with CSS Loaded From Merchant's Web Site

Slight variation from above: payment service provider wants to be able to theme the page that collects cardholder data, so it loads CSS stylesheets from a link hosted on merchant's web site.

This is SAQ-A-EP, because the CSS which is an integral part of the page that collects cardholder data is loaded from the merchant's web site, which can impact the overall security of the page (even though the page itself is loaded from service provider).

Merchant Embeds Service Provider's iframe to Collect Data, iframe Directly Sends Data to Provider's Server

Payment service provider provides merchant with a way to load an iFrame on top of merchant's own web page (sometimes, service provider can also load iFrames that look like individual controls, not necessarily a page, such as card number input box); cardholder enters data directly into the iFrame.

This is SAQ-A, because what cardholder interacts with to enter cardholder data is completely originated from payment service provider, in other words, merchants have no way to peek into the data.

Conclusion

For any online merchants who accept card payments, they at least need to attest compliance with PCI-DSS SAQ-A. This is the easiest SAQ as the merchants do not collect, transmit, process or store cardholder data at all during the online transactions.

Many payment service providers have tools for merchants who process payments with them to easily enter information to complete SAQ. This guided approach makes SAQ completion less of a pain. Payment service providers then report compliance on behalf of the merchants to card networks.

All payment service providers who are PCI-DSS compliant can provide merchants with their own PCI-DSS attestation. This is useful for merchants in operations and business development, for example, to obtain a business insurance.