ETA Expert Insights: PCI DSS Validation Responsibilities for Payment Facilitators and Their Sub-Merchants

By Jim Bibles, Aperia, Chris Bucolo, ControlScan, and Lori Rainery First American Payment Systems, members of the ETA Payment Facilitator Committee.

There are many misconceptions around the responsibilities of Payment Card Industry Data Security Standard (PCI DSS) validation for both Payment Facilitators (Payment Facilitator’s) and their Sub-merchants.  This stems from the fact that Payment Facilitator’s and their sub-merchants are a vast community with different business models and integration types, each potentially impacting the validation requirements of the Payment Facilitator, as an entity, and the underlying validation requirements of the sub-merchants.  However, one thing is constant: Both the Payment Facilitator and the sub-merchant need to comply with the PCI DSS.

Validation of the Payment Facilitator as an Entity

It is a best practice to take PCI DSS compliance into consideration during the design phase of a Payment Facilitator product offering.  Doing so will save time and money for the organization, as bolting security in later is very expensive and can disrupt the workflow of the solution, making it no longer as user- friendly or frictionless as it was originally designed to be.

A Payment Facilitator must be PCI DSS compliant BEFORE they process their first transactions and many acquirers will not sign a Payment Facilitator without proof of compliance.  The type of verification that is required is dependent on the acquirer, but can range from a Self-Assessment Questionnaire (SAQ), to a third-party audit by a PCI Security Standard Council certified Qualified Security Assessor (QSA).  If a Payment Facilitator is given the option of self- certification, the best practice is at a minimum to bring in a QSA for a gap assessment.  It is important to note that requiring the full- blown QSA audit is now the norm for the acquiring industry  and it is a prerequisite to being listed on the Visa Global Service Provider Registry   (https://usa.visa.com/splisting/splistingindex.html). A list of PCI SSC QSA organizations can be found at  www.pcisecuritystandards.org .

Often there is confusion over the need to have the application the PAYMENT FACILITATOR provides to its merchants validated and certified as Payment Application- Data Security Standard (PA-DSS) compliant.  The PA- DSS requirement only comes into play if the application is an “off the shelf application,” not an application that is hosted at the Payment Facilitator and integrated into their solution.  If the payment application is integrated into the solution and not for sale as a stand-alone application, the expectation is that this application would be included in the overall PCI DSS review, which will look at the total security of the application and its development process.

If the Payment Facilitator is asserting that its solution satisfies PCI DSS requirements on behalf of the sub-merchant, these requirements must be identified during the review and documented.

Validation of the sub-merchants as an Entity

All entities that store, process, or transmit cardholder data are required to comply with PCI.  As sub-merchants are separate legal entities from the payment facilitator, they have their own obligations under the card brand rules to adhere to the PCI DSS.  It is not enough to assert that a Payment Facilitator and the solution they provide to the sub-merchant are compliant, and thus the sub-merchant is compliant.  The sub-merchant must understand their obligations and ensure that they operate in a PCI DSS compliant manner.

The chain of liability [1] is in full effect, and any PCI DSS violations that occur at the sub-merchant will generate liability for both the Payment Facilitator and the acquiring entity.

It is a best practice to have all sub-merchants validate compliance.  A Payment Facilitator needs to understand their sub-merchants processing environment and ensure that they are using the correct validation documentation for the type of transaction processing that occurs at the sub-merchant.  If certain PCI DSS requirements are addressed by the Payment Facilitator solution, then the sub-merchant needs to be educated to that effect, so that it can be appropriately documented on their validation documentation.

Note: Many PCI DSS validations providers can customize the validation process to account for this situation.

Understanding the impact of the Payment Facilitator solution/offering on sub-merchant validation

When any entity validates PCI, they must first understand where and how they store, process, and transmit cardholder data.  For sub-merchants of a Payment Facilitator this will be dictated by the Payment Facilitator’s offering, how it is integrated into the merchant network and the type of data the sub-merchant has access to.  Below are some processing examples and their associated validation requirements:

• A fully hosted e-commerce solution that includes a payment page hosted and managed by the Payment Facilitator – (SAQ A)
• A browser- based application hosted and managed by the Payment Facilitator that is accessed by the sub-merchant to enter cardholder data for a transaction process, but no cardholder data is stored at the sub-merchant – (SAQ C-VT)
• An application that resides in the merchant’s environment, but utilizes an iframe or encrypted reader to capture cardholder data and transmit it directly to the Payment Facilitator. The merchant does not have access to the cardholder data (SAQ-C or A-EP depending on the transaction type)
• An application that resides in the merchant’s environment and utilizes API’s to transmit transactional information including cardholder data. (SAQ D)

This is just a sample of the most common integration types, and there are some sub-requirements on these SAQs that may be addressed by the Payment Facilitator solution.  However, if the Payment Facilitator is asserting that their solution meets security requirements contained within the various SAQs, it must be documented within the Payment Facilitator Report On Compliance (ROC) and clearly identified within the sub-merchant’s SAQ that they are reliant on the Payment Facilitator for the prevision on these services.  Additionally, these services must be present in the agreement between the sub-merchant, and the Payment Facilitator must comply with requirement 12.8.2 of the PCI DSS.

Card brand requirements

Visa

Visa classifies Payment Facilitators as Service Providers and requires that they register as such. This registration process will require that the Payment Facilitator demonstrate compliance with the PCI DSS as outlined below:

Level 1 Service Provider:  A Level 1 Service Provider is an entity that stores, transmits, or processes more than 300,000 total Visa accounts/ transactions annually.

Each Level 1 Service Provider must validate compliance with the Payment Card Industry Data Security Standard, each TSP must additionally validate compliance with the PCI TSP Security Requirements, and each 3-DSSP must validate compliance with the PCI 3DS Core Security Standard by successfully completing:

• An Attestation of Compliance onsite by a PCI SSC-approved QSA every 12 months.  Note – Visa reserves the rights to request the supporting Report on Compliance (ROC)

Level 2 Service Providers:  A Level 2 Service Provider is any Service Provider that stores, transmits, or processes 300,000 or less total combined Visa accounts/transactions annually.

Each Level 2 Service Provider must provide an Attestation of compliance every 12 months for a PCI SSC Self-Assessment Questionnaire “D”

NOTE – A Report on compliance by a QSA is required to be placed on the Visa Global Registry of Service Providers, regardless of the service provider level.

MasterCard

Mastercard classifies payment facilitators as service providers and requires that they register as such. This registration process will require that the Payment Facilitator demonstrate compliance with the PCI DSS as outlined below:

Level 1 Service Providers:  A Level 1 Service Provider is any TPP, SDWO, DASP, TSP, or 3-DSSP (regardless of volume); and any DSE or PF that stores, transmits, or processes more than 300,000 total combined Mastercard and Maestro Transactions annually.

Each Level 1 Service Provider must validate compliance with the Payment Card Industry Data Security Standard, each TSP must additionally validate compliance with the PCI TSP Security Requirements, and each 3-DSSP must validate compliance with the PCI 3DS Core Security Standard by successfully completing:

• An annual on-site assessment by an appropriate PCI SSC-approved QSA, and
• Quarterly network scans conducted by a PCI SSC ASV.

Mastercard recommends that each Level 1 Service Provider demonstrates to Mastercard its compliance with the Designated Entities Supplemental Validation (DESV) appendix of the PCI DSS.

Level 2 Service Providers:  A Level 2 Service Provider is any DSE or PF that is not deemed a Level 1 Service Provider and that stores, transmits, or processes 300,000 or less total combined Mastercard and Maestro Transactions annually; and any TS.

Each Level 2 Service Provider must validate compliance with the Payment Card Industry Data Security Standard by successfully completing:

• An annual self-assessment, and
• Quarterly network scans conducted by a PCI SSC ASV.

Mastercard recommends that each Level 2 Service Provider demonstrate to Mastercard its compliance with the DESV appendix of the PCI DSS.

[1]“The payment facilitator is responsible for ensuring its merchants comply with the Payment Card Industry Data and Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA DSS), KYC requirements, anti-money laundering rules and other applicable security standards.” – Visa Inc.