- Get Started
- Guides
- Integrations
- References
- API Reference
- Basic Payment
- Forex
- Authentication
- Card Account
- Apple Pay
- Virtual Account
- Bank Account
- Token Account
- Customer
- Billing Address
- Merchant Billing Address
- Shipping Address
- Merchant Shipping Address
- Merchant
- Corporate
- Recipient
- Marketplace & Cart
- Airline
- Lodging
- Passenger
- Tokenization
- Recurring Migration
- 3D Secure
- Custom Parameters
- Async Payments
- Webhook notifications
- Job
- Risk
- Point of Sale
- Response Parameters
- Card On File
- Chargeback
- Result Codes
- Payment Methods
- Transaction Flows
- Regression Testing
- Data Retention Policy
- API Reference
- Support
- Impressum
PCI DSS Guide
Last updated:September 23, 2024
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 and trustworthy.
PCI DSS Essentials
Introduction to PCI DSS
The Payment Card Industry Data Security Standard (PCI DSS) is a global security standard established by major credit card companies—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 organization that stores, processes, or transmits cardholder data. Compliance helps protect cardholder data, reduce fraud, and minimize the risk of data breaches. It also helps maintain 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 1Install and maintain network security controls.
- Requirement 2Apply secure configurations to all system components.
- Requirement 3Protect stored cardholder data.
- Requirement 4Use strong cryptography during transmission over open, public networks.
- Requirement 5Protect systems and networks from malicious software.
- Requirement 6Develop and maintain secure systems and software.
- Requirement 7Restrict access to system components and cardholder data by business need to know.
- Requirement 8Identify users and authenticate access to system components.
- Requirement 9Restrict physical access to cardholder data.
- Requirement 10Log and monitor all access to system components and cardholder data.
- Requirement 11Test security of systems and networks regularly.
- Requirement 12Support information security with organizational policies and procedures.
PCI DSS Compliance Levels
Compliance levels are based on the volume of credit card transactions processed annually:
- Level 1: Over 6 million transactions or any organization 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 (SAQ)
Different 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, especially 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 comply with storage requirements if applicable.
Evolution to PCI DSS 4.x
Welcome to the future of payment security with PCI DSS 4.x! This latest version brings groundbreaking changes designed to enhance security, flexibility, and risk management. Here’s what you need to know:
- 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.
- Customizable 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 will be 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!
Admin compliance
Ensure seamless compliance with PCI DSS 4.x for master user account administrators.
How it works
Actions required
Find out what actions you need to take as a merchant or Payment Service Provider (PSP).
1. 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.1An access control model is defined and includes granting access as follows:- Appropriate access depending on the entity’s business and access needs.
- Access to system components and data resources that is based on users’ job classification and functions.
- The least privileges required (for example, user, administrator) to perform a job function.
- Job classification and function.
- Least privileges necessary to perform job responsibilities.
- At least once every six months.
- To ensure user accounts and access remain appropriate based on job function.
- Any inappropriate access is addressed.
- Management acknowledges that access remains appropriate.
2. How to comply
To comply with PCI DSS v4.x, specifically the 7.2.x requirements, all user accounts and access privileges, including those of third-party vendors, must be reviewed at least every six months to ensure they are appropriate for the user’s job function. These reviews must be conducted by your organization’s administrators.
3. Actions required
As a master user account administrator, you are responsible for managing and reviewing all user accounts under your organization’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.
- Promptly addressing any inappropriate access.
- Obtaining management acknowledgment that access remains appropriate.
Scripts compliance
Ensure seamless compliance with PCI DSS 4.x for payment scripts.
How it works
Actions required
Find out what actions you need to take as a merchant or Payment Service Provider (PSP).
1. 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 e-commerce 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 unauthorized changes on payment pages.
- A method is implemented to confirm that each script is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written justification as to why each is necessary.
- To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser.
- The mechanism is configured to evaluate the received HTTP header and payment page.
- The mechanism functions are performed at least weekly or periodically (at the frequency defined in the entity’s targeted risk analysis.
2. How to comply
To meet PCI DSS v4.x Requirement 6.4.3, merchants have the following options:
- Traditional methods, like a combination of Content Security Policy (CSP), Subresource Integrity (SRI), and scanning to detect changes.
- Monitoring from within content delivery networks (CDN).
- Comprehensive JavaScript security management solutions provided by a third party.
While it is possible to adopt third party's solutions, with SecurePay the authorization and integrity of the script is always available using traditional methods.
3. Actions Required
Authorization of the scripts
Content Security Policy (CSP) can be used to specify which sources of content are allowed to be loaded on the page, including scripts, images, and other resources. This ensures that only authorized scripts are loaded on the payment page.The steps are:
- Add CSP: Configure a CSP header to specify allowed sources for scripts and other resources on your page. The CSP header to be used for SecurePay can be found at the following link
- Test CSP: The recommendation is to start with Report-Only CSP to monitor violations without enforcing them. Use tools like CSP Evaluator to refine your policy.
Verify scripts integrity
Subresource Integrity (SRI)
can be used to verify the integrity of scripts. SRI ensures that resources loaded are delivered without being manipulated or
tampered with by malicious actors. The SRI hash is added 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 will not load the resource.
How to Verify the Integrity of SecurePay
SecurePay is a script dynamically generated and unique for each payment session. The SRI hash must be generated and returned for each checkout. For this reason implements SecurePay provides a Dynamic SRI feature. A new parameter has been added and must be included in Step 1 Create Checkout call to generate the SRI hash. The hash will be returned in the response, allowing integrators to support a smooth transition for existing integrations.
The steps to follow are:
- Generate SRI Hash: Include a new parameter in the Step 1 Create Checkout call to generate the SRI hash. The hash will be returned in the response.
-
Add SRI: Add the SRI hash to the
integrity
attribute of the<script>
element on the payment page. - Verify Integrity: The browser ensure that the SRI hash matches the fetched resource to prevent loading tampered scripts.
Example of Request and Response with the new parameter
Requestcurl https://eu-test.oppwa.com/v1/checkouts -d "entityId=8a8294175d602369015d73bf009f1808" -d "amount=92.00" -d "currency=EUR" -d "paymentType=DB" -d "integrity=true" -H "Authorization: Bearer OGE4Mjk0MTc1ZDYwMjM2OTAxNWQ3M2JmMDBlNTE4MGN8ZE1xNU1hVEQ1cg=="Response
{ "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" }
Adding the Widget to the Payment Page
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 will check the integrity of the script, and if it finds that the script was manipulated or tampered with, it will 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 with the reason for each script. The following scripts are the ones that SecurePay loads from third parties:
Reason | Script |
---|---|
Device Fingerprint | https://*.iovation.com/snare.js |
Klarna | https://*.klarnacdn.net/kp/lib/v1/api.js |
PayPal | https://*.paypal.com/da/r/fb.js |
Affirm | https://*.affirm.com/js/v2/affirm.js |
Amazon Pay | https://*.payments-amazon.com/checkout.js |
Oney | https://*.oney.io/build/loader.min.js |
After Pay | https://*.afterpay.com/afterpay.js |
Mastercard | https://src.mastercard.com/srci/integration/2/lib.js,https://src.mastercard.com/srci/integration/components/src-ui-kit/src-ui-kit.esm.js |
RatePay | https://d.ratepay.com/*/di.js |
RocketFuel | https://d3rpjm0wf8u2co.cloudfront.net/static/rkfl.js |
SamsungPay | https://d35p4vvdul393k.cloudfront.net/sdk_library/us/stg/ops/pc_gsmpi_web_sdk.js,https://d16i99j5zwwv51.cloudfront.net/sdk_library/us/prd/ops/pc_gsmpi_web_sdk.js |
Sezzle | https://checkout-sdk.sezzle.com/checkout.min.js |
Yandex | https://yookassa.ru/checkout-widget/v1/checkout-widget.js |
https://pay.google.com/gp/p/js/pay.js | |
Apple | https://applepay.cdn-apple.com/jsapi/v1.1.0/apple-pay-sdk.js |
Alirisk | https://cdn10.ebuckler.com/ebuckler.widget.js,https://stats.ebuckler.com/js/ebuckler.widget.js |
Masterpass | https://*.masterpass.com/lightbox/Switch/integration/MasterPass.client.js |
Please note that, depending on the integration, this list is related only to SecurePay and may not be the full list of scripts that are loaded on the website.
Monitoring and Detection
Customers need to implement monitoring and detection themselves to be PCI SAQ-A compliant with the payment widget.
- Implement Monitoring: Set up monitoring tools to detect any unauthorized 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 UI passwords and API Bearer tokens.
How it works
Actions required
Find out what actions you need to take as a merchant or Payment Service Provider (PSP).
1. 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.6If passwords/passphrases are used as authentication factors, they meet the following minimum level of complexity:- A minimum length of 12 characters.
- Contain both numeric and alphabetic characters.
2. How to comply
To meet PCI DSS v4.x Requirement 8.3.6, our product enhances password security and transitions to hashed credentials.
- We have already improved password complexity and update frequency. UI user account passwords must be at least 12 characters long, containing both numeric and alphabetic characters, and must be updated every 42 days in both UAT and Production environments.
- To further enhance security, we are working on hashing credentials for both passwords and API Bearer tokens. This transition from encryption to hashing will ensure that passwords are complex, lengthy, and random, preventing attackers from easily guessing or discovering them.
3. Actions Required
- UI User Passwords: Users must save their UI user account passwords securely (e.g., in a key store). If the password is not properly and securely saved, the user will need to 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 UI or merchant onboarding API. If the access token is not properly and securely saved, the user will need to create a new SYSTEM user to generate a new API Bearer token. There is always a 1-to-1 mapping between a SYSTEM user used in processing and the API Bearer token.