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.

MERCHANT LEVEL	LEVEL DESCRIPTION (VISA OR MASTERCARD)	REDIRECT (HOSTED) IFRAME HOSTED FIELDS	DIRECT POST	API ONLY	PCI DSS   VALIDATION REQUIREMENTS
1	Over 6 million Any merchant that Visa or Mastercard, at its sole discretion, determines should meet the Level 1 merchant requirements. Any merchant that has experienced a data breach that resulted in an account data compromise may be escalated to a higher level.	ROC	ROC	ROC	Annual on-site audit by a QSA  or internal staff accredited by   the PCI SSC (annual accreditation) Quarterly network scan conducted by an ASV [2]
2	1 – 6 million	SAQ A	SAQ A-EP	SAQ D	Annual self-assessment. or on-site assessment       at the merchant’s discretion Attestation of compliance form (AOC) Quarterly network scan conducted by an ASV [2]
3	20,000 – 1 million	SAQ A	SAQ A-EP	SAQ D	Annual self-assessment questionnaire Attestation of compliance form (AOC) Quarterly network scan conducted by an ASV [2]
4	Under 20,000	SAQ A	SAQ A-EP	SAQ D	Recommended annual self-assessment questionnaire Recommended quarterly network scan conducted by an ASV [2]

[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.

When criminals attack hosted integrations
How?	Using a technique called the man-in-the-middle (MITM) attack, criminals break the security of the merchant website and change the program that sends the redirect instruction to the customer’s device, telling it to request a payment form from the criminal’s website instead of the PSP’s. The card data entered by the customer is sent to the criminal and not to the PSP. Sometimes the criminal’s website collects the card data and sends it onto the PSP; sometimes the criminal’s website gets the card data, tells the customer that there’s been a problem and sends an instruction to the customer’s device to now get the "real" payment form from the PSP.
What will the cardholder see?	The criminal’s payment form, which will be designed to look identical to the PSP’s payment form and may also ask for other information such as the cardholder’s PIN. Depending on how the criminals attack, the cardholder may be asked to enter their card data twice.
What will the merchant see?	The merchant may see a loss in sales caused by an increased transaction drop-out as customers are not taken in by the criminal’s payment form or don’t want to enter their card data twice.
How can the merchant detect this attack?	E-commerce merchants should ensure that regular checks of their website are carried out for any new or unknown web pages or files. In particular, merchants should regularly check that the code redirecting their customers to the third party hosted payment page is the same code that was provided to them by the third party and has not been modified.  • If the code that links to the hosted payment page is integrated into a merchant’s shopping cart, e-commerce merchants should ensure that their shopping cart application is patched with the most up-to-date version available. • E-commerce merchants should discuss security with their web hosting provider and ensure they have secured their systems appropriately. Web and database servers should be hardened to disable default settings and unnecessary services. Many international system hardening standards exist such as those provided by the Center for Internet Security and merchants should encourage their web host provider to adopt these standards. • E-commerce merchants that utilise web hosting providers or third-party payment providers that store, process or transmit cardholder data must maintain on-going compliance to the Payment Card Industry Data Security Standard (PCI DSS). E-commerce merchants should ensure that data security language is present in all contracts with entities that store, process or transmit cardholder data on their behalf. These contracts should clearly identify roles and responsibilities for how cardholder data should be protected.
Risk rating	Low – this method of processing e-commerce payments is the lowest risk for merchants.

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.

When criminals attack iFrame integrations
How?	Using a technique called the man-in-the-middle (MITM) attack, attacks against  iFrame integrations are very similar to attacks against hosted integrations.    Criminals break the security of the merchant website and change the program that creates the parent page sent to the customer’s device. Instead of the instruction telling the customer’s device to request a child page containing a payment form from the PSP, it tells it to request a payment form from the criminal’s website. When the customer enters their card data, it is thus sent to the criminal’s website and not to the PSP’s. Sometimes the criminal’s website collects the card data and sends it onto the PSP; sometimes it gets the card data, tells the customer that there’s been a problem and sends an instruction to the customer’s device to now get the "real" payment form from the PSP.
What will the cardholder see?	The criminal’s payment form, which will be designed to look identical to the PSP’s payment form and may also ask for other information such as the cardholder’s PIN. Depending on how the criminals attack, the cardholder may be asked to enter their card data twice.
What will the merchant see?	The merchant may see a loss in sales caused by an increased transaction drop-out as customers are not taken in by the criminal’s payment form or don’t want to enter their card data twice.
How can the merchant detect this attack?	E-commerce merchants should ensure that regular checks of their website are carried out for any new or unknown web pages or files. In particular, merchants should regularly check that the code redirecting their customers to the third-party hosted payment page is the same code that was provided to them by the third party and has not been modified.  • If the code that links to the hosted payment page is integrated into a merchant’s shopping cart, e-commerce merchants should ensure that their shopping cart application is patched with the most up-to-date version available. • E-commerce merchants should discuss security with their web hosting provider and ensure that they have secured their systems appropriately. Web and database servers should be hardened to disable default settings and unnecessary services. Many international system hardening standards exist such as those provided by the Center for Internet Security and merchants should encourage their web host provider to adopt these standards. • E-commerce merchants that utilise web hosting providers or third-party payment providers that store, process or transmit cardholder data must maintain on-going compliance to the Payment Card Industry Data Security Standard (PCI DSS). E-commerce merchants should ensure that data security language is present in all contracts with entities that store, process or transmit cardholder data on their behalf. These contracts should clearly identify roles and responsibilities for how cardholder data should be protected.
Risk rating	Low – this method of processing e-commerce payments is low risk although it is more frequently attacked by criminals than hosted integrations. Merchants should ask their PSP about technical measures they can use to best secure an iFrame.

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.

When criminals attack Direct Post integrations
How?	Criminals break the security of the merchant website and change the program that creates the payment form. The criminals include some script so that when the customer enters their card data, it is automatically sent to the criminals as well as to the PSP.
What will the cardholder see?	The legitimate payment form. The cardholder will not notice the script running in the background, which also sends the card data to the criminal.
What will the merchant see?	The merchant will not see any effects of this attack in their day-to-day operations.
How can the merchant detect this attack?	As detection by the merchant is very hard, the merchant should deploy the appropriate PCI DSS controls described in SAQ A-EP to help prevent and detect this attack.
Risk rating	Medium – this method of processing e-commerce payments is higher risk than the hosted or the iFrame mode.

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

 

5.4. JavaScript integration

When criminals attack JavaScript integrations
How?	Criminals break the security of the merchant website and change the program that creates the payment page that is sent to the customer’s device. The criminals change the page in order for the customer’s device to request JavaScript from the criminal’s website in addition to JavaScript from the PSP so that when the customer enters their card data, as well as the card data being sent to the PSP, it is also sent automatically to the criminals.
What will the cardholder see?	The payment form. The cardholder will not notice the additional script running in the background of the payment form on their computer that also sends the card data to the criminals.
What will the merchant see?	The merchant will not see any effects of this attack in their day-to-day operations.
How can the merchant detect this attack?	As detection by the merchant is very hard, the merchant should deploy the appropriate PCI DSS controls described in SAQ A-EP to help prevent and detect this attack.
Risk rating	Medium

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.

When criminals attack API integrations
How?	Criminals break the security of the merchant website and change the program which receives the card data from the payment form so that the card data is also stored on the hard disk of the merchant website. Criminals then return to the merchant website to download the card data.
What will the cardholder see?	The payment form. The cardholder will not notice any difference.
What will the merchant see?	The merchant will not see any effects of this attack in their day-to-day operations but an examination of the web server will normally show the attack by the criminals.
How can the merchant detect this attack?	Requirements 10 and 11 in the PCI DSS are designed to detect criminals attempting to break into and alter a system.
Risk rating	High – criminals are very likely to attack merchant websites that process cardholder data. Most data compromises occur on merchant websites that use this type of integration.

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.