PCI DSS v4.0.1 Compliance for South African Merchant Aggregators

South Africa's payment ecosystem is becoming increasingly digital, with merchants and consumers using online card payments, mobile channels, electronic transfers, and real-time payment services. Payment aggregators operate across several layers of this ecosystem, connecting merchants with payment processors, acquirers, payment platforms, and other service providers. This position can create complex technology environments where payment card data may be stored, processed, transmitted, or exposed to systems that can affect the security of the cardholder data environment.

PCI DSS v4.0.1 provides a global security baseline for entities that store, process, or transmit cardholder data or can affect the security of the cardholder data environment. The standard applies to organisations across the payment chain, including merchants, processors, acquirers, issuers, and service providers.

For South African merchant aggregators, PCI DSS v4.0.1 should therefore be considered alongside South Africa's payment-system requirements and privacy obligations under the Protection of Personal Information Act, or POPIA. PCI DSS does not replace local regulatory requirements, and POPIA does not replace PCI DSS. Each framework addresses a different part of the risk and regulatory environment.

Protect cardholder data with PCI DSS v4.0.1 Compliance. Strengthen payment security and demonstrate adherence to industry requirements.

PCI DSS v4.0.1 for South African Merchant Aggregators

What PCI DSS v4.0.1 Requires

PCI DSS v4.0.1 establishes technical and operational requirements designed to protect payment account data. The standard covers areas including network security controls, secure configurations, account-data protection, access control, authentication, logging, monitoring, vulnerability management, security testing, and information security policies.

PCI DSS v4.0.1 is a limited revision of PCI DSS v4.0. PCI Security Standards Council states that v4.0.1 did not introduce new or deleted requirements. It clarified existing requirements and corrected errors and formatting issues. PCI DSS v4.0 was retired on 31 December 2024, making v4.0.1 the active version after that date.

The future-dated requirements from PCI DSS v4.x became effective on 31 March 2025. Merchant aggregators operating today therefore need to consider the applicable v4.0.1 requirements within their PCI DSS assessment scope.

Who Needs PCI DSS Compliance?

PCI DSS is intended for organisations that store, process, or transmit cardholder data or sensitive authentication data, as well as entities that can affect the security of the cardholder data environment. This includes payment processors and service providers involved in payment card processing.

A South African merchant aggregator may therefore fall within PCI DSS scope when its technology, infrastructure, applications, personnel, or services handle payment card data or can affect the security of systems handling that data.

The exact validation obligation can depend on the organisation's role, payment relationships, acquiring arrangements, payment brands, transaction environment, and applicable validation programme. PCI SSC states that payment brands, acquirers, or other organisations managing compliance programmes determine whether an entity must validate PCI DSS compliance and which validation method applies.

PCI DSS Scope for Merchant Aggregators

PCI DSS scope should be based on the actual flow of payment account data and the systems that can affect the security of the cardholder data environment.

For a merchant aggregator, relevant components may include payment gateways, APIs, databases, web applications, cloud environments, authentication systems, administrative interfaces, network infrastructure, logging platforms, security monitoring technologies, and third-party services.

Third-party relationships are particularly important. PCI SSC states that service providers may include organisations directly involved in processing, storing, or transmitting cardholder data, including payment gateways and payment service providers.

Outsourcing payment processing does not automatically remove PCI DSS responsibilities. Organisations must understand which activities are performed by third parties, what remains within their environment, and how responsibilities are divided between the parties.

PCI DSS Requirements for Payment Aggregators

Cardholder Data Protection

Merchant aggregators should establish where cardholder data enters the environment, where it is processed, whether it is stored, where it travels, and which systems can access it.

PCI DSS Requirement 3 addresses protection of stored account data, while Requirement 4 addresses protection of cardholder data during transmission over open, public networks.

Data minimisation can also reduce exposure. Where payment architecture permits, organisations can evaluate whether sensitive payment data needs to be retained and whether technologies such as tokenisation or validated point-to-point encryption can reduce the exposure of cardholder data.

Tokenisation does not automatically remove all PCI DSS responsibilities. Scope depends on the technology, architecture, connections, and functions involved.

Network Security and Segmentation

Merchant aggregators commonly operate interconnected environments involving merchant portals, payment APIs, processing systems, databases, cloud infrastructure, administrative systems, and external service providers.

Network security controls and segmentation can restrict unnecessary communication between environments and reduce the potential impact of a compromise. PCI DSS Requirement 1 addresses network security controls, while Requirement 2 addresses secure configurations for system components.

Segmentation should be assessed according to the actual architecture rather than assumed simply because separate network zones exist.

Access Control and MFA

Payment platforms contain systems that may provide access to cardholder data or security-sensitive components. PCI DSS therefore places significant emphasis on restricting access according to business need and authenticating users before access to system components.

Requirement 7 addresses access restrictions, while Requirement 8 addresses user identification and authentication.

Multi-factor authentication can be particularly important for administrative access and other environments where unauthorised access could affect the security of payment systems. Organisations should also manage privileged accounts, authentication credentials, access reviews, and account lifecycle controls according to the applicable PCI DSS requirements.

Secure Payment Applications

Payment aggregators frequently depend on web applications, APIs, mobile applications, merchant dashboards, and backend services. Vulnerabilities within these applications can create risks for payment data and transaction integrity.

PCI DSS Requirement 6 focuses on developing and maintaining secure systems and software. PCI DSS v4.x also introduced additional controls addressing payment page scripts and e-commerce security. These requirements became effective from 31 March 2025.

Application security should therefore cover secure development practices, vulnerability identification, change management, protection against common application threats, and appropriate security testing.

Logging and Monitoring

Real-time payment environments generate large volumes of authentication events, API requests, administrative actions, transaction activity, system events, and security alerts.

PCI DSS Requirement 10 addresses logging and monitoring access to system components and cardholder data. Effective monitoring should provide sufficient visibility to identify suspicious activity and investigate security events.

Logs should be protected from unauthorised alteration and retained according to the applicable PCI DSS requirements and organisational needs.

Vulnerability Management and Security Testing

Payment aggregators should maintain processes for identifying vulnerabilities across systems within PCI DSS scope. This includes infrastructure, applications, networks, cloud environments, and other relevant technologies.

PCI DSS Requirement 11 addresses regular testing of security systems and networks. Depending on the applicable requirements and environment, security testing can include vulnerability scanning, penetration testing, wireless testing, network testing, and other specified testing activities.

External vulnerability scans required under PCI DSS must be performed by a PCI SSC Approved Scanning Vendor where the applicable requirement calls for an ASV scan.

Incident Response and Security Policies

Payment aggregators need defined processes for responding to suspected or confirmed security incidents involving payment environments.

PCI DSS Requirement 12 addresses information security policies and organisational programmes. Security policies should establish responsibilities, escalation paths, incident response expectations, third-party responsibilities, and other security requirements relevant to the organisation's environment.

For a payment aggregator, incident response should also consider dependencies on acquirers, payment processors, payment brands, cloud providers, and other third parties.

Securing Real-Time Payment Rails in South Africa

Real-Time Payment Security Risks

Real-time payments reduce transaction processing time, but faster transaction flows can also reduce the time available to detect and respond to suspicious activity.

South Africa's Rapid Payments Programme resulted in PayShap, a retail instant-payment service launched commercially in March 2023. The South African Reserve Bank describes PayShap as a real-time payment system designed to provide a safe, trusted, interoperable payment infrastructure.

Merchant aggregators connecting card payment environments with broader digital payment ecosystems therefore need to consider authentication, API security, transaction monitoring, fraud detection, access control, data protection, and third-party dependencies.

Payment API Security

APIs are central to modern payment platforms. Merchant onboarding, transaction initiation, payment status, refunds, reconciliation, authentication, and merchant reporting may all rely on APIs.

API security should include strong authentication, authorisation controls, secure credential management, input validation, encryption, rate limiting where appropriate, monitoring, secure error handling, and protection against common API attacks.

API endpoints that interact with cardholder data require particular attention because weaknesses can affect both application security and PCI DSS scope.

Transaction Monitoring

Real-time payment environments require visibility into unusual transaction behaviour. Monitoring can consider transaction frequency, unusual account activity, authentication anomalies, unexpected API behaviour, geographic inconsistencies, and other indicators defined by the organisation's fraud and security processes.

Transaction monitoring should complement, rather than replace, PCI DSS security controls. PCI DSS primarily establishes requirements for protecting payment account data and the systems that handle or can affect that data.

Encryption and Tokenization

Encryption is a core component of protecting payment data, particularly when cardholder data travels over open, public networks.

Tokenisation can also reduce the exposure of primary account numbers by replacing sensitive payment data with tokens within appropriate payment architectures. However, tokenisation does not automatically make an environment entirely outside PCI DSS scope.

The actual scope depends on how the tokenisation solution operates, which systems can access account data, and whether other systems can affect the security of the cardholder data environment.

Fraud and Account-Takeover Risks

Merchant aggregators may face risks from stolen credentials, automated attacks, compromised merchant accounts, phishing, malicious API activity, and payment fraud.

PCI DSS controls such as authentication, access restriction, secure configurations, logging, monitoring, vulnerability management, and security testing can address important parts of the technical risk environment.

Fraud management, however, involves additional business and payment controls beyond PCI DSS. Organisations should therefore avoid treating PCI DSS as a complete fraud-prevention framework.

Third-Party Payment Provider Security

Merchant aggregators frequently depend on third-party payment processors, cloud platforms, hosting providers, security vendors, and other technology providers.

PCI DSS Requirement 12.8 addresses relationships with third-party service providers. PCI SSC states that organisations should understand third-party responsibilities and maintain appropriate oversight of providers connected to the cardholder data environment.

A third party being PCI DSS compliant does not automatically make every connected organisation compliant. The responsibilities of each party need to be clearly understood within the payment architecture and validation process.

PCI DSS and South African Payment Regulations

PCI DSS and POPIA

POPIA and PCI DSS address different requirements.

POPIA focuses on the lawful processing and protection of personal information in South Africa. Section 19 requires responsible parties to take appropriate, reasonable technical and organisational measures to protect the integrity and confidentiality of personal information and prevent unauthorised access or processing. The Information Regulator also states that responsible parties must identify foreseeable internal and external risks and maintain appropriate safeguards.

PCI DSS focuses specifically on payment account data and the security of systems involved in payment card processing.

A merchant aggregator may therefore have obligations under both frameworks. For example, customer information processed alongside payment information may fall within POPIA, while cardholder data and systems affecting the cardholder data environment may fall within PCI DSS.

South African Payment-System Requirements

South Africa's payment-system regulatory environment is also evolving. In 2026, the South African Reserve Bank transferred payment-system management functions previously associated with the Payments Association of South Africa to the SARB and PayInc. The SARB states that regulation, authorisation, and standards functions moved to the SARB, while PayInc took responsibility for specified payment clearing functions, including PayShap and real-time clearing.

The SARB also lists a directive concerning cybersecurity and cyber-resilience within the national payment system.

Merchant aggregators should therefore consider the regulatory requirements applicable to their specific payment role, authorisation status, payment relationships, and services.

PCI DSS vs Local Regulatory Obligations

PCI DSS is an industry security standard rather than a substitute for South African legislation or payment-system regulation.

For South African merchant aggregators, the relevant compliance environment may include PCI DSS, POPIA, payment-system requirements, contractual obligations from acquiring banks and payment brands, and other applicable financial-sector requirements.

The frameworks can overlap in areas such as access control, security safeguards, incident management, third-party oversight, and technology risk, but meeting one framework does not automatically establish compliance with another.

PCI DSS v4.0.1 Compliance Process

Define PCI DSS Scope

Identify the systems, applications, networks, people, facilities, services, and third parties that store, process, transmit, or can affect the security of cardholder data.

Map Cardholder Data Flows

Document how cardholder data enters the environment, where it is processed, whether it is stored, where it moves, and which systems or third parties interact with it.

Identify Applicable Requirements

Determine which PCI DSS v4.0.1 requirements apply based on the actual environment and assessment scope. The applicable validation method should be confirmed with the relevant acquiring entity, payment brand, or other organisation responsible for the compliance programme.

Apply Security Controls

Establish the applicable technical and operational controls covering network security, secure configurations, account-data protection, access control, authentication, vulnerability management, application security, logging, monitoring, testing, and information security policies.

Perform Required Security Testing

Carry out the security testing required for the applicable PCI DSS requirements and assessment type. Where PCI DSS specifies an Approved Scanning Vendor, the required external vulnerability scanning should be performed by an approved provider.

Validate Compliance

The appropriate validation method depends on the entity's role and compliance programme. Service providers should not assume that a merchant Self-Assessment Questionnaire determines the requirements applicable to their own assessment. PCI SSC states that service providers assessed through an SAQ use SAQ D for Service Providers where eligible, while all applicable PCI DSS requirements must be considered within the assessment scope.

Maintain Ongoing Compliance

PCI DSS compliance should be maintained as payment architecture, applications, vendors, infrastructure, data flows, and security risks change. Regular monitoring, vulnerability management, access reviews, testing, incident response, and third-party oversight remain important throughout the payment environment's lifecycle.

PCI DSS Compliance Checklist for Payment Aggregators

A South African merchant aggregator can use the following areas when reviewing its PCI DSS environment:

Cardholder data environment identified
Cardholder data flows documented
Cardholder data appropriately protected
Network security controls established
Relevant network segmentation evaluated
Multi-factor authentication applied where required
Privileged access restricted
Payment applications securely developed and maintained
Security vulnerabilities identified and addressed
Logs collected and monitored
Required security testing performed
External vulnerability scans completed where applicable
Incident response procedures established
Third-party service providers identified
Third-party responsibilities documented
Security policies maintained
PCI DSS validation requirements confirmed with the relevant compliance-accepting entity

Strengthen security across your cardholder data environment. PCI DSS v4.0.1 addresses access control, encryption, monitoring, vulnerability testing, and more. Explore PCI DSS assessment services with INTERCERT.

Why Choose INTERCERT for PCI DSS Certification?

INTERCERT is a PCI DSS Qualified Security Assessor (QSA) providing independent PCI DSS assessment services for organisations that need to demonstrate conformity with applicable PCI DSS requirements.

As a QSA, INTERCERT assesses the applicable cardholder data environment against PCI DSS requirements based on the organisation's defined scope, payment environment, systems, processes, and applicable validation requirements.

For South African merchant aggregators, payment processors, payment gateways, and other organisations handling cardholder data, QSA-led assessment is particularly relevant where formal PCI DSS validation is required by an acquiring bank, payment brand, or other applicable compliance programme.

INTERCERT's PCI DSS assessment expertise covers payment environments involving cardholder data, payment applications, networks, APIs, cloud infrastructure, access controls, vulnerability management, logging, monitoring, security testing, and third-party service relationships.