Last updated: 2026-01-25

Imagine a world where your customers' payment data is always secure, transactions are seamless, and trust is never compromised. That's the peace of mind PCI DSS brings. It safeguards cardholder data, reduces fraud, and ensures your business remains compliant.

Introduction to PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard established by Visa, Mastercard, American Express, Discover, and JCB through the Payment Card Industry Security Standards Council (PCI SSC) in 2006. It aims to protect cardholder data and ensure trust in the payment ecosystem.

Importance of PCI DSS

PCI DSS applies to any organisation that stores, processes, or transmits cardholder data. Compliance helps protect cardholder data, reduce fraud, and reduce the risk of data breaches. It also helps build customer trust and avoid significant penalties and costs associated with non-compliance.

PCI DSS requirements

PCI DSS includes 12 main requirements and over 300 sub-requirements, covering:

• Build and maintain a secure network and systems:
  • Requirement 1: Install and maintain network security controls.
  • Requirement 2: Apply secure configurations to all system components.
• Protect cardholder data:
  • Requirement 3: Protect stored cardholder data.
  • Requirement 4: Use strong cryptography during transmission over open, public networks.
• Maintain a vulnerability management program:
  • Requirement 5: Protect systems and networks from malicious software.
  • Requirement 6: Develop and maintain secure systems and software.
• Implement strong access control measures:
  • Requirement 7: Restrict access to system components and cardholder data by business need to know.
  • Requirement 8: Identify users and authenticate access to system components.
  • Requirement 9: Restrict physical access to cardholder data.
• Regularly monitor and test networks:
  • Requirement 10: Log and monitor all access to system components and cardholder data.
  • Requirement 11: Test security of systems and networks regularly.
• Maintain an information security policy:
  • Requirement 12: Support information security with organisational policies and procedures.

PCI DSS compliance levels

Compliance levels differ depending on the volume of credit card transactions processed annually:

• Level 1: Over 6 million transactions or any organisation that has experienced a data breach.
• Level 2: 1 to 6 million transactions.
• Level 3: 20 000 to 1 million online transactions.
• Level 4: Fewer than 20 000 online transactions or up to 1 million total transactions.

PCI DSS self-assessment questionnaire

Different self-assessment questionnaire (SAQ) types apply based on the payment integration method:

• SAQ A: Card-not-present merchants outsourcing all account data functions.
• SAQ A-EP: eCommerce merchants partially outsourcing payment processing.
• SAQ B: Merchants using imprint machines or standalone, dial-out terminals.
• SAQ B-IP: Merchants using standalone, PTS-approved payment terminals with an IP connection.
• SAQ C-VT: Merchants manually entering payment data via a virtual terminal.
• SAQ C: Merchants with internet-connected payment application systems.
• SAQ P2PE: Merchants using a validated, PCI-listed point-to-point encryption solution.
• SAQ SPoC: Merchants using a mobile device with a secure card reader.
• SAQ D: All other merchants and service providers.

PCI DSS roles and responsibilities

Implementing PCI DSS can be complex and costly for merchants without an existing security framework. Payment Service Providers (PSPs) offer integrations that handle most PCI DSS requirements, simplifying compliance. However, merchants still need to ensure cardholder data is secure before it reaches the PSP.

• PSP's responsibility: Secure cardholder data once received through the payment interface.
• Merchant's responsibility: Secure cardholder data before it reaches the PSP and adhere to storage requirements if applicable.

Evolution to PCI DSS 4.x

Version 4.x of PCI DSS brings groundbreaking changes designed to enhance security, flexibility, and risk management:

• Stronger authentication: Expanded multi-factor authentication (MFA) requirements ensure robust protection for all access points.
• Password upgrades: Say goodbye to weak passwords with new minimum complexity requirements.
• Customisable controls: Tailor security measures to fit your unique environment with flexible implementation options.
• Continuous vigilance: Embrace ongoing risk assessments to stay ahead of evolving threats.
• Advanced monitoring: Enhanced logging and detection capabilities for swift incident response.
• Tech-ready: Adapt seamlessly to emerging technologies like mobile payments and cloud environments.

Effective March 31, 2024, PCI DSS 4.x becomes the new standard, setting a higher bar for payment security. Get ready to elevate your security posture and protect your cardholder data like never before!

Administrative compliance

Ensure seamless compliance with PCI DSS 4.x for master user account administrators.

Overview

1. Updates in PCI DSS 4.x: Discover the new requirements introduced in PCI DSS 4.x.
2. How to comply: Learn how Peach Payments products meet these new requirements.
3. Actions required: Find out what actions you need to take as a merchant or payment service provider (PSP).

Updates in PCI DSS 4.x

PCI DSS 4.x introduces new requirements designed to ensure that access to system components and data is appropriately defined and assigned.

Requirement 7.2.1

You've designed an access control model which includes granting access as follows:

• Appropriate access depending on the entity's business and access needs.
• Access to system components and data resources based on users' job classification and functions.
• The least privileges required (for example, user, administrator) to perform a job function.

Purpose: Defining an access control model that is appropriate for the entity's technology and access control philosophy supports a consistent and uniform way of allocating access and reduces the possibility of errors such as the granting of excessive rights.

Good practice:

• Consider the principle of separation of duties to prevent fraud, misuse, or theft of resources.
• Divide critical functions among different individuals or roles, such as system management, programming, and quality assurance.
• Avoid granting end-to-end control of processes to a single individual. Assign responsibilities like configuration and approval to separate people.

Requirement 7.2.2

Assign access to users, including privileged users, based on:

• Job classification and function.
• Least privileges necessary to perform job responsibilities.

Purpose: Assigning the least privileges helps prevent unauthorised or accidental changes to application configuration or security settings. It also reduces damage scope if criminals compromise an account.

Good practice: Grant access based on specific user roles, ensuring you assign the minimum necessary privileges. For privileged access, adhere to the principle of least privileges.

Requirement 7.2.4

Review all user accounts and related access privileges, including third-party and vendor accounts:

• At least once every six months.
• To ensure user accounts and access remain appropriate based on job function.
• Address any inappropriate access.
• Management acknowledges that access remains appropriate.

Purpose: Regular reviews detect and address excessive or outdated access rights, reducing the risk of misuse or unauthorised access. Reviews also ensure terminated users or vendors no longer have access.

Good practice:

• Revalidate access during role or department changes to prevent misuse or errors.
• Roll out regular, repeatable processes for access rights reviews.
• Assign data owners responsible for monitoring and managing access.

How to comply

For PCI DSS 4.x, specifically the 7.2.x series of rules, you must review all user accounts and access privileges (including third-party vendors) at least every six months. Your organisation's administrators must conduct the reviews to ensure appropriateness based on job functions.

Actions required

As a master user account administrator, you are responsible for managing and reviewing all user accounts under your organisation's master account starting March 31, 2025. It is advisable to begin this process sooner. Your responsibilities include:

• Reviewing user accounts and access privileges at least every six months.
• Ensuring access remains appropriate based on job functions.
• Addressing any inappropriate access.
• Obtaining management acknowledgement that access remains appropriate.

Managing and reviewing your organisation's user accounts and adhering to the above guidelines is essential for maintaining the security and integrity of your systems and data.

Scripts compliance

Ensure seamless compliance with PCI DSS 4.x for payment scripts.

Overview

1. Updates in PCI DSS 4.x: Discover the new requirements introduced in PCI DSS 4.x.
2. How to comply: Learn how Peach Payments products meet these new requirements.
3. Actions required: Find out what actions you need to take as a merchant or payment service provider (PSP).

Updates in PCI DSS 4.x

PCI DSS 4.x introduces new requirements to enhance control over how payment pages manage loaded scripts, aiming to detect and prevent eCommerce skimming attacks, a major cause of cardholder data breaches. The new requirements focus on two main areas:

• Protecting public-facing web applications against attacks.
• Detecting and responding to unauthorised changes on payment pages.

Requirement 6.4.3

Manage all payment page scripts that you load and execute in the consumer's browser as follows:

• Implement a method to confirm the authorisation of each script.
• Implement a method to ensure the integrity of each script.
• Keep an inventory of all scripts with written justification why each is necessary.

Requirement 11.6.1

Deploy a change and tamper detection mechanism as follows:

• Alerts personnel to unauthorised modification (for example, indicators of compromise, changes, additions, deletions) to HTTP headers and payment page content as received by the consumer browser.
• Configured to check received HTTP headers and payment page content.
• Performed weekly or periodically per the entity's risk analysis.

How to comply

To meet PCI DSS v4.x requirement 6.4.3, merchants can choose from:

• Traditional methods (for example, CSP, SRI, scanning).
• Monitoring in CDNs.
• Comprehensive JavaScript security management solutions.

For COPYandPAY, the authorisation and integrity of scripts are always available using traditional methods.

Actions required

Authorisation of scripts

Use CSP to specify the support of specific content sources on the page:

1. Add CSP: Configure a CSP header to specify allowed sources for scripts. Learn more about CSP header details for COPYandPAY in the support section.
2. Test CSP: Start with Report-Only mode to check violations without enforcing them. Use tools like CSP Evaluator to refine your policy.

Verify script integrity by using SRI to ensure attackers can't tamper with loaded resources. SRI ensures the delivery of loaded resources without manipulation by attackers. Add the SRI hash to the integrity attribute when specifying a <script> element on the page. If the browser detects that the file's hash does not match the specified hash, the browser does not load the resource.

COPYandPAY is a script dynamically generated and unique for each payment session. You must generate and return the SRI hash for each checkout. For this reason, COPYandPAY provides a dynamic SRI feature. Peach Payments has added a new parameter that you must include in the Create Checkout call to generate the SRI hash. The response includes the hash, allowing integrators to support a smooth transition for existing integrations.

1. Generate SRI hash: Include a new parameter in the Create Checkout call to generate the SRI hash. The response includes the hash.
2. Add SRI: Add the SRI hash to the integrity attribute of the <script> element.
3. Verify integrity: Ensure the browser matches the SRI hash with the fetched resource.

curl https://sandbox-card.peachpayments.com/v1/checkouts \
-d "entityId=8a8294175d602369015d73bf009f1808" \
-d "amount=92.00" \
-d "currency=EUR" \
-d "paymentType=DB" \
-d "integrity=true" \
-H "Authorization: Bearer OGE4Mjk0MTc1ZDYwMjM2OTAxNWQ3M2JmMDBlNTE4MGN8ZE1xNU1hVEQ1cg=="

{
  "result": {
    "code": "000.200.100",
    "description": "successfully created checkout"
  },
  "buildNumber": "577c5667d790266430da6bb4c0effd313f92bb8a@2024-08-28 00:42:29 +0000",
  "timestamp": "2024-08-29 10:44:20+0000",
  "ndc": "52252F000AA2C1BEB0A0F728B5119AB0.uat01-vm-tx01",
  "id": "52252F000AA2C1BEB0A0F728B5119AB0.uat01-vm-tx01",
  "integrity": "sha384-Uz9kJ7MP7hR4osV9qZgnqzAUaqeNOjwtCvpcQYvXmi61KPRg1EwdT+G1gYpVuEok"
}

To render the widget on the payment page and verify its integrity, include the SRI hash retrieved from the integrity parameter in the response in the integrity attribute of the <script> element:

<script
  src="https://eu-test.oppwa.com/v1/paymentWidgets.js?checkoutId={checkoutId}"
  integrity="sha384-Uz9kJ7MP7hR4osV9qZgnqzAUaqeNOjwtCvpcQYvXmi61KPRg1EwdT+G1gYpVuEok"
  crossorigin="anonymous"
></script>

The browser checks the integrity of the script, and if it finds that someone manipulated or tampered with the script, it does not load it.

Scripts inventory

To fully comply with requirement 6.4.3, merchants must keep an inventory of all the scripts that load on the website along with the reason for each script. The following scripts are the ones that COPYandPAY loads from third parties:

📘

Depending on the integration, this list pertains only to COPYandPAY and might not represent the full list of scripts that load on the website.

Monitoring and detection

To be PCI SAQ-A compliant with the payment widget, merchants need to implement monitoring and detection on their own:

• Implement monitoring: Set up monitoring tools to detect any unauthorised access or anomalies.
• Regular reviews: Conduct regular reviews of the monitoring logs to identify and address potential security issues.

Credentials compliance

Ensure seamless PCI DSS 4.x compliance for user interface passwords and API bearer tokens.

Overview

1. Updates in PCI DSS 4.x: Discover the new requirements introduced in PCI DSS 4.x.
2. How to comply: Learn how the product meets these new requirements.
3. Actions required: Find out what actions you need to take as a merchant or payment service provider (PSP).

Updates in PCI DSS 4.x

PCI DSS 4.x introduces new requirements to better protect credentials (passwords or API tokens), including the establishment and management of strong authentication for users and administrators.

Requirement 8.3.6

Passwords or passphrases must meet the following minimum level of complexity:

• A minimum length of 12 characters.
• Contain both numeric and alphabetic characters.

How to comply

To meet PCI DSS v4.x Requirement 8.3.6, the product enhances password security and transitions to hashed credentials.

• Improved password complexity and update frequency.
  • User interface user account passwords must be at least 12 characters long, containing both numeric and alphabetical characters.
  • You must update passwords every 42 days in both UAT and production environments.
• To further enhance security, Peach Payments is working on hashing credentials for both passwords and API bearer tokens.
  • This transition from encryption to hashing ensures passwords are complex, lengthy, and random, making it difficult for attackers to guess or discover them.

Actions required

• User interface user passwords:
  • Users must securely save their user interface user account passwords (for example, in a key store).
  • If the password is not securely saved, the user must request a new one from the master user account administrator.
• API bearer tokens:
  • Customers must securely store the API bearer token upon creation of a merchant entity via user interface or merchant onboarding API.
  • If the access token is not securely saved, the user must create a new SYSTEM user to generate a new API bearer token.
  • A 1-to-1 mapping between a SYSTEM user used in processing and the API bearer token always exists.

Prepare for the upcoming transition to hashed credentials to stay ahead of compliance requirements.