1.  Understanding the Payment Card Industry Data Security Standard

1.1. What is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security standards established by the PCI Security Standards Council (PCI SSC), an independent body founded in September 2006 by five major credit card networks: American Express, Discover, JCB International, Mastercard and Visa Inc.

The PCI SSC is responsible for the development and on-going evolution of security standards for account data protection. As a set of industry-mandated requirements, PCI DSS applies to any business that handles, processes or stores credit card data, regardless of its location or size.

PCI DSS is designed to identify vulnerabilities in security processes, procedures and website configurations. Compliance helps all stakeholders protect themselves against security breaches, while enhancing consumer confidence and protecting the overall integrity of the payment system.

PCI DSS compliance applies to all servers hosting merchant websites that accept Mastercard and/or Visa credit cards, even if the web servers do not store, process or transmit cardholder data (as they determine how cardholder data is processed and can thus affect the security of the transaction).

 

2.  Merchant Levels and Validation Requirements

2.1. Compliance vs. validation

Compliance and validation are two separate and distinct processes.

Compliance:     

• PCI DSS mandate that applies to any business that handles, processes or stores payment data regardless of its location or size.

         Such businesses should all be compliant at all times.

• An on-going and not a one-time exercise.

Validation:       

• Visa and Mastercard require that merchants demonstrate their compliance status based on merchant levels.

All merchants fall into one of the four merchant levels and validation requirements, which are defined by Visa and Mastercard based on transaction volumes over a 12-month period, the potential risk and the exposure.

Transaction volume is based on the aggregate number of Visa or Mastercard transactions processed by a corporate entity from all its merchants Doing Business As (‘DBAs’). If the corporate entity does not store, process or transmit cardholder data on behalf of multiple DBAs, the DBA’s individual transaction volume determines the validation level.

 

2.2. Validation requirements

There are two ways merchants can validate their PCI DSS compliance:

• By obtaining a Report on Compliance (ROC) issued by a PCI SSC registered Internal Security Assessor (ISA) or Qualified Security Assessor (QSA) – mandatory for level 1 merchants and discretionary for level 2;

OR

• By completing a Self-Assessment Questionnaire (SAQ) – for merchants that qualify;

        (The type of SAQ form depends on the type of integration that you choose)

AND

• By performing a Network Scan using a PCI DSS Approved Scanning Vendor for all levels 1 to 3, recommended for level 4.

 

To align with payment scheme rules, HiPay requires merchants to validate their PCI DSS compliance:

• at the time of on-boarding as part of the underwriting process;
• for new project launch, including change of integration, payment page customisation, adding payment methods Visa and/or Mastercard;
• annually thereafter.

 

The following table [1] indicates the volume of transactions and the appropriate annual validation requirements at each level.

[1] Source: Visa and Mastercard

[2] Approved Scanning Vendor

 

3.  Self-Assessment Questionnaires (SAQs)

3.1. Which SAQ is right for me?

An SAQ is a PCI DSS document, which is a validation tool for merchants and payment service providers (PSPs) who are not required to undergo on-site assessments for PCI DSS compliance.

There are different types of SAQs and the following information will help you determine the SAQ form that applies to your processing setup.

 

3.2. HiPay, your PCI DSS compliant service provider

HiPay is a Visa and Mastercard listed PCI DSS compliant third-party provider.

While outsourcing may simplify the scope of PCI DSS compliance for the merchant, it does not eliminate the merchant’s risk and responsibility for basic security measures.

Regardless of the extent of outsourcing to a third-party service provider, the merchant retains the responsibility for ensuring that payment card data is protected. Connections and redirections between the merchant and the third-party PSP can be compromised, allowing unauthorised access to the merchant site; hackers then change the payment pathway between the merchant and the PSP who believe that they are directly communicating with each other. Therefore, merchants should monitor their systems to ensure that no unexpected changes have occurred and that the integrity of the connection and redirection is maintained at all times.

PCI DSS validation requirements as a merchant depend on how you choose to integrate HiPay as your payment service provider (PSP).

HiPay offers the following integration methods:

• Hosted Page and iFrame
• Direct Post
• Hosted Fields
• Hosted Payments
• API only

 

3.3. SAQ A

• The merchant does not store, process or transmit cardholder data electronically,
• All payment processing functions are fully outsourced, hosted and managed by HiPay,

OR

• The merchant website provides an iFrame or URL that redirects customers to HiPay, where no elements of the page originate from the merchant website.

 

3.4. SAQ A-EP

• The merchant website does not store, process or transmit cardholder data but controls how the data is collected,
• The merchant website provides an iFrame or URL that redirects customers to HiPay,

BUT some elements of the payment page originate from the merchant website    

(elements would be JavaScript, a CSS or any functionality that supports how the payment page is created),

OR

• The merchant website creates a payment form and uses a Direct Post integration to send data to HiPay.

 

3.5. SAQ D

• The merchant website stores, processes or transmits cardholder data,
• All PCI DSS requirements apply.

4.  What To Do If Compromised

Entities must investigate suspected or confirmed loss, theft, compromise, fraud of account or cardholder information.

Entities that have experienced a suspected or confirmed security breach must take prompt action to help prevent additional exposure of cardholder data and ensure PCI DSS compliance.

1. Immediately contain and limit the exposure and minimise data loss. Prevent further loss of data by ceasing to process credit card transactions and diverting payments to a known secure channel.

2. Immediately report any suspected or confirmed security breach directly to your dedicated HiPay Account Manager.

3. The payment schemes may require that a merchant engage an accredited PCI Forensic Investigator (PFI) to conduct a thorough forensic investigation of the suspected or confirmed data breach. It is vitally important that the compromised environment or payment channel remains untouched and intact to preserve evidence and facilitate the investigation.

As a guide:

• Do not access or alter compromised system(s) (i.e. do not log on at all to the compromised system(s) and change passwords; do not log in as ROOT).

• Do not turn the compromised system(s) off. Instead, isolate the compromised system(s) from the network (e.g. unplug network cable).

• Preserve logs (e.g. security events, web, database, firewall, etc.). Log all actions taken.

• If using a wireless network, change the Service Set Identifier (SSID) on the Wireless Access Point (WAP) and other systems that may be using this connection (with the exception of any systems believed to be compromised).

• Be on "high" alert and monitor traffic on all systems with cardholder data.

Please refer to Visa, What to do if you’re compromised by a security incident.

 

5.  Data Breaches based on the Type of Integration [3]

5.1. Redirect/hosted integration

The PSP creates the payment form and sends it to the customer’s device. The PSP receives the card data sent directly to the payment system for authorisation. The merchant does not receive the card data.

For more details, please see the HiPay technical documentation on our Developer Portal.

 

5.2. iFrame integration

iFrame integrations allow cardholders to fill in their payment card information on a secure payment page hosted by the PSP and displayed in an iFrame inside the merchants’ payment page.

For more details, please see the HiPay technical documentation on our Developer Portal.

 

5.3. Direct Post integration

With JavaScript, Direct Post integrations allow merchants to create their own payment form, hosted on their server. Once customers validate the form, card data is sent to the PSP, which returns a token. Merchants can then process payments with the token on their server. That way, payment data (e.g. card number, card verification code…) never hits the merchants’ server as it remains in the browser and is sent directly to the PSP’s secure vault.

For more details, please see the HiPay technical documentation on our Developer Portal.

 

5.4. JavaScript integration

For more details, please see the HiPay technical documentation on our Developer Portal.

 

5.5. API integration

With API integrations, the merchant website creates a payment form and sends it to the customer’s device. Card data is then sent from the customer’s device to the server of the merchant before being transmitted to the PSP. The merchant website may also store this information.

For more details, please see the HiPay technical documentation on our Developer Portal.

[3] Source: Visa

 

6.  Helpful and Related Links

For more information on the PCI security standards and the Card Association Compliance Programs, go to:

 

Industry websites:

Visa Europe Payment Security

Mastercard Worldwide SDP Program

Mastercard offers a complimentary education series on PCI DSS at PCI 360.

Discover Information Security & Compliance (DISC)

 

PCI Security Standards Council documents:

Requirements and Security Assessment Procedures

Visit the PCI Security Standards Council website for the most up-to-date documents.

 

Helpful PCI DSS documentation:

Understanding the SAQs for PCI DSS version 3

PCI DSS 3.2: What’s New?

MOTO – Protecting Telephone-based Payment Card Data

PCI DSS Quick Reference Guide – Understanding the Payment Card Industry Data Security Standard version 3.1

 

7.  Glossary of Terms

Approved Scanning Vendor (ASV)

Provides commercial software tools to perform vulnerability scans for networks and systems (computer, server and router); identifies and reports back any vulnerabilities where a hacker could easily gain access to a merchant’s servers. [4]

You can find further information and download a list of qualified assessors by visiting the PCI Security Standards Council website.

 

Attestation of Compliance (AOC)

A PCI DSS document that must be completed for all service providers validating PCI DSS compliance.

Please visit the PCI Security Standards Council website to download the relevant documentation.

 

Cardholder Data Environment (CDE)

The people, processes and technology that store, process, or transmit cardholder data or sensitive authentication data.

 

On-site or self-assessment

A detailed assessment performed by a PCI SSC certified Qualified Security Assessor (QSA) or by a certified Internal Security Assessor (ISA). The assessment validates to the acquirer that the organisation is handling card data in accordance with the Payment Card Industry Data Security Standard.

 

Payment Card Industry Data Security Standard (PCI DSS)

A security standard owned and managed by the PCI Security Standards Council (PCI SSC).

PCI DSS includes 12 requirements for any business that stores, processes or transmits payment card or account data. These requirements specify the framework for a secure payments environment.

 

PCI Security Standards Council (PCI SSC)

The PCI SSC was founded by Visa Inc., Mastercard, JCB International, Discover and American Express.    

You can find more information on the PCI Security Standards Council website.

 

Point Of Sale (POS)

Hardware and/or software used to process payment card transactions at merchant locations.

 

Qualified Security Assessor (QSA)

Independent experts who provide consulting services for PCI assessments. QSA companies have trained personnel and processes to assess and prove compliance with the PCI DSS. For further information and to download a list of QSAs, please visit the PCI Security Standards Council website.

 

Report on Compliance (ROC)

A PCI DSS document containing details documenting a business’ compliance status with the PCI DSS requirements. This is completed by a Qualified Security Assessor (QSA) when an on-site audit is conducted.

 

Self-Assessment Questionnaire (SAQ)

A PCI DSS document, which is a validation tool for merchants and service providers who are not required to do on-site assessments for PCI DSS compliance.

For further information and to download this form, please visit the PCI Security Standards Council website.

[4] PCI DSS requirement 11.2

 

More information: https://www.pcisecuritystandards.org/pci_security/glossary 

 

8.  Frequently Asked Questions (FAQs)

My payment processor is PCI compliant; do I still need to be PCI compliant?

Yes. There is a common misconception that outsourcing payment processing to a PCI DSS compliant service provider renders the merchant compliant and eliminates the need to be compliant.

Although HiPay payment services simplify the scope of your PCI DSS compliance by securely processing card data for you, all merchants still need to validate their PCI DSS compliance.

Outsourcing to a PCI DSS compliant payment service provider does not automatically make a merchant compliant or eliminate the responsibility and requirement for merchants to ensure that the payment card data is protected.

 

Are the PCI DSS validation requirements determined by HiPay?

No, the payment schemes along with the acquirers define the PCI DSS validation requirements for the various merchant levels.

 

How often do I need to validate my PCI DSS compliance with HiPay?

In accordance with the payment scheme validation requirements, HiPay requires validation of PCI DSS at the time of merchant on-boarding and annually thereafter for all level 1-3 merchants processing Visa and/or Mastercard transactions. Level 4 merchants are recommended to validate.

 

What is the difference between PCI DSS Compliance vs. Validation?

Compliance is an on-going and not a one-time exercise. SAQs are a validation tool for eligible merchants and service providers to demonstrate that they have evaluated their PCI DSS compliance through a self-assessment.

• It represents a snapshot of the moment in time when the self-assessment and vulnerability scans are done.

• A single system change can introduce new vulnerabilities and in turn non-compliance.

• After that moment, only another assessment or post-breach forensic analysis can prove PCI DSS compliance.

 

What are the consequences of non-compliance with PCI DSS?

The consequences of not being PCI DSS compliant are determined and enforced by the individual payment schemes.

• Your customer data may be at risk of compromise and fraudulent use.

• The cost of a forensic investigation can run into thousands of euros. Non-compliant merchants may be liable for non-compliance fines, which can run from tens to hundreds of thousands of euros. You would be liable for the cost if evidence of a breach is established. The fines are assessed by the payment card schemes to the acquirer/PSP and then passed onto the merchant.

• Post breach, a merchant will be required to validate PCI DSS compliance according to level and requirements, regardless of the actual level.

• Possible suspension of credit card acceptance by the payment schemes.

• Reputational damage and loss of business. Following a data breach, businesses are faced with the challenge of retaining customers’ trust.