What is the Right SAQ for You?

Introduction

Payment Brands have categorised merchants into four different levels (Level 1, Level 2, Level 3 and Level 4) according to the volume of transactions they carried out every year. Merchants are required to demonstrate their trustworthiness by complying with the PCI DSS requirements that are put forth by PCI SSC council.

There are two ways for a merchant to validate their compliance with PCI DSS depending on the volume of transactions:

Completing a Self-Assessment Questionnaire (SAQ) OR
By obtaining a Report on Compliance (ROC) engaging a PCI Security Standards Council registered Qualified Security Assessor (QSA).

All e-commerce merchant falling under Level 1 category, must go for an annual onsite PCI DSS assessment by a QSA. Others will qualify for one of the three SAQ Types SAQ-A, SAQ- A-EP and SAQ-D depending on how the card information is handled by them.

Identifying the right SAQ

Now, you might be wondering why there are more than one SAQ for E-Commerce merchants. Well, the applicability of these SAQs depends upon how the merchant’s website or web server is configured to accept card payments. PCI SSC has varied minimum requirements for e-commerce merchants depending on how they accept cardholder data and the number of card transactions they process annually. However, it is ideal for the merchants to contact their acquiring bank to confirm the validation method they need to use.

Let’s discuss further on the eligibility criteria as defined by payment brands to determine which compliance validation is best suited for different E-commerce merchant type. We can summarize these validation requirements citing the table given in VISA Europe’s Processing E-commerce Payments Guide:

RoC A – Partial Report on Compliance Validating the Scope, Eligibility and Requirements listed in SAQ A

RoC A-EP – Partial Report on Compliance Validating the Scope, Eligibility and Requirements listed in SAQ A-EP

The difference in efforts

PCI DSS is applicable to all merchant environments even if the cardholder data is not stored, processed or transmitted in the webserver itself as it is the merchant’s web server that determines how the cardholder data is being processed and can thereby affect the security of the transaction.

Selecting the right SAQ will be critical in achieving compliance in its right intent, while ensuring optimum effort from the team.

The number of technical requirements applicable depends upon how the payment flow is configured and what relevant SAQ an organisation is pursuing. The following table provides a high-level overview of the validation requirements to be implemented by e-commerce merchants are seeking to be PCI DSS compliant.

SAQ A Merchant:

In a typical SAQ-A Merchant environment, all the processing of cardholder data is entirely outsourced to PCI DSS validated third-party, which means the payment pages which are delivered to the consumer’s browser should originate directly from a PCI DSS compliant third-party service provider. Here, the merchant can choose any one of the following methods to integrate with the third-party service provider.

Over a Web Redirect
By loading an inline-frame (i-frame)

The Redirect Process

Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process passing over the payment coordinates and security checksums. Following diagram illustrates web redirect process.

Capturing payment over an iFrame

The iFrame of the PCI DSS compliant third-party processor is embedded in the merchant website which enables the consumer to process the payment with the third-party processor. Following diagram illustrates payment process over an iFrame.

SAQ A-EP Merchant

Direct Post to Payment Processor

In this method, the merchant website captures the payment information over a form, and the payment data is delivered directly from the consumer browser to the payment processor over a direct POST or browser API calls. Following diagram illustrates payment process over a direct post to third party processor.

The JavaScript Post

In this method, the merchant website loads or delivers script which will run in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.

Following diagram illustrates payment process with JavaScript to third party processor.

SAQ D-Merchant:

Any e-commerce merchant that stores credit card data and the volume of transaction is less than 6 million transaction will by default fall under SAQ D. The payment pages will be delivered from the merchant’s website and card data will be entered on the same. All e-commerce merchants that cannot meet the criteria for SAQ A or SAQ A-EP, fall under the umbrella of SAQ D. Following diagram illustrates payment process with server to server communication to third party processor.