Skip to content

    PCI DSS

    Overview

    The Payment Card Industry Data Security Standards (PCI DSS) is a set of security standards for businesses that handle credit cards from the major card schemes. Its aim is to provide security requirements that help protect sensitive credit card data (also known as the Cardholder Data Environment CDE)

    The CDE defines the storage, processing and transmission of credit card information. All merchants that accept credit cards must meet PCI compliance with varying requirements depending on a number of factors. These are laid down in different assessments, of which the Self Assessment Questionnaires (SAQ) are the most common ones.

    PCI Compliance for Ecommerce Websites

    As an ecommerce merchant you need to become familiar with the importance of PCI compliance. Even though the PCI DSS must be met by all merchants that process, store or transmit cardholder data, a formal validation of PCI DSS compliance is not compulsory for all merchants. Currently, both Visa and MasterCard require merchants and service providers to be validated annually according to the PCI DSS. If a security breach occurs, any compromised entity which did not comply with PCI DSS at the time of breach will face additional penalties (e.g. fines) by card schemes.

    PCI Requirements

    The PCI requirements are divided into 6 major categories with 12 requirements in total:

    Build and Maintain a Secure Network

    • Requirement 1 - Install and maintain a firewall.
    • Requirement 2 - Do not use vendor-supplied defaults for system passwords or other security parameters.

    Protect Cardholder Data

    • Requirement 3 - Protect stored cardholder data.
    • Requirement 4 - Encrypt transmission or cardholder data across public networks.

    Maintain a Vulnerability Management Program

    • Requirement 5 - Protect all systems against malware and regularly update anti-virus programs.
    • Requirement 6 - Develop and maintain secure systems and applications.

    Implement Strong Access Control Measures

    • Requirement 7 - Restrict access to card holder data by business need-to know.
    • Requirement 8 - Identify and authenticate access to system components.
    • Requirement 9 - Restrict physical access to card holder data.

    Regularly Test and Monitor Networks

    • Requirement 10 - Track and monitor all access to network resources and card holder data.
    • Requirement 11 - Regularly test security systems and processes.

    Maintain an Information Security Policy

    • Requirement 12- Maintain an information security policy.

    The above listed 12 requirements cover different business aspects that in turn break down into more than 200 sub-requirements. Each of these sub-requirements is represented by a check box in the SAQ that a merchant is obliged to follow.

    Self Assessment Questionnaires (SAQ)

    Regarding ecommerce merchants, we need to focus specifically on SAQ Type A, SAQ Type A-EP and SAQ Type D. The type of SAQ depends on the way a merchant handles credit card data:

    SAQ A:

    • Merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
    • All payment acceptance and processing are entirely outsourced to PCI DSS validated third-party service providers;
    • Merchant has no direct control of the manner in which cardholder data is captured, processed, transmitted, or stored;
    • Merchant does not electronically store, process, or transmit any cardholder data on his systems or premises, but relies entirely on a third party(s) to handle all these functions;
    • Merchant has confirmed that all third party(s) handling acceptance, storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
    • Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically.
    • Additionally, for e-commerce channels: The entirety of all payment pages delivered to the consumer’s browser originates directly from a third-party PCI DSS validated service provider(s).

    SAQ A-EP:

    • Merchant accepts only e-commerce transactions;
    • All processing of cardholder data is outsourced to a PCI DSS validated third-party payment processor;
    • Merchant's e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;
    • Merchant's e-commerce website is not connected to any other systems within his environment (this can be achieved via network segmentation to isolate the website from all other systems);
    • If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);
    • All elements of payment pages that are delivered to the consumer’s browser originate from either the merchant’s website or a PCI DSS compliant service provider(s);
    • Merchant does not electronically store, process, or transmit any cardholder data on his systems or premises, but relies entirely on a third party(s) to handle all these functions;
    • Merchant has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
    • Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

    SAQ D-Merchant

    • E-commerce merchant that cannot meet the criteria for SAQ A or SAQ A-EP, OR
    • E-commerce merchant that stores credit card data, OR
    • Payment pages are delivered from the merchant’s website.

    Defining your scope with PCI

    Concerning PCI, it all comes down to reducing scope. Scope depends on the way a merchant handles credit cards on his site (i.e., how a customer enters his information and where it goes). The following aspects should be thought of in terms of the CDE:

    • Storage: How will the data be stored (e.g. store it as an organization or use a third-party provider)?
    • Transmission: How will the data be transmitted (e.g. how will the data proceed to the gateway and are there any SSL Certificates in place)?
    • Collection: How will the data be collected (e.g. through a form on or off the page)?
    • Processing: How will the data be processed (e.g. locally by the merchant or through a service provider)?

    Depending on the specific choices above, it impacts which SAQ you must fulfill and the corresponding precautions you have to take to ensure security. In general, it is highly recommended for ecommerce merchants not to store or process credit card data within their environment (locally) and instead leverage us to do this. In this case, you are only obliged to meet the fairly decent requirements laid down by SAQ A or SAQ A-EP. Whether SAQ A, SAQ A-EP or SAQ D apply, is determined by the checkout type as follows:

    Checkout TypeSAQ
    REST API (for all payment methods, especially Cards)D
    JS Bridge (with merchant forms for Cards) + REST API (for all other payment methods)AEP
    JS Bridge (with iFrame forms for Cards) + REST API (for all other payment methods)A
    Widget (JS: as lightbox)A
    Widget (JS: inline / iFrame)A
    Widget (JS: as bridge)A
    Dynamic Payment Page (redirect, dynamic parameters via API)A
    Static Payment Page (redirect to static URL)A

    Merchant PCI Portal (Security Center)

    You are required to provide the necessary merchant data on our PCI portal.

    Please request access via your Concardis sales manager. For further details, please refer to the Concardis page in English or in German.

    The corresponding SAQs (Version 3.2) can be found here: SAQ A SAQ A-EP SAQ D

    Was this helpful?

    What was your feeling about it?