FAQ Section
Disputes and Compliance

What Is PCI DSS and Who Must Comply?

 

What the PCI DSS standard requires, which merchants and providers must comply, and how hosted checkouts and tokenisation reduce your PCI scope.

PCI DSS — the Payment Card Industry Data Security Standard — is the global security standard for protecting card data. It is set by the PCI Security Standards Council, founded by the major card schemes, and applies to every organisation that stores, processes or transmits cardholder data, from the largest processor down to a small online shop.

PCI DSS is not South African legislation; it is a contractual requirement enforced through the card schemes and your acquiring bank. But the practical effect is the same: if you accept card payments, some level of PCI DSS compliance applies to you.

What does PCI DSS require?

The standard is organised around a set of core security goals:

  • Build and maintain secure networks and systems (firewalls, no vendor default passwords)
  • Protect stored cardholder data and encrypt it in transit
  • Maintain vulnerability management (anti-malware, secure development, patching)
  • Implement strong access control (need-to-know access, unique IDs, physical security)
  • Monitor and test networks (logging, monitoring, security testing)
  • Maintain an information security policy

The recurring theme is simple: card data must be protected everywhere it exists, and the fewer places it exists, the easier that is.

Who must comply, and at what level?

Everyone who handles card data must comply, but the validation burden scales with transaction volume. The schemes define merchant levels — from Level 1 for the highest-volume merchants down to Level 4 for the smallest — where higher levels require formal on-site assessments by a Qualified Security Assessor, and lower levels can self-assess.

Self-assessment is done through a Self-Assessment Questionnaire (SAQ), and the SAQ type depends on how you accept cards:

SAQ typeTypical scenarioRelative burden
SAQ ACard entry fully outsourced to a hosted payment page or redirect; you never touch card dataLightest
SAQ A-EPE-commerce where your website affects how card data is captured (e.g. embedded fields you control)Moderate
SAQ B / B-IPStandalone card terminals, no electronic storageLight to moderate
SAQ DYou store, process or transmit card data in your own systemsHeaviest

How do you reduce your PCI scope?

The most effective compliance strategy is to keep card data out of your systems entirely:

  • Use a hosted checkout or redirect. When your payment provider's hosted page captures the card, your website never sees the number, and your validation typically reduces to SAQ A — the lightest option.
  • Use tokenisation for repeat billing. Store your provider's token, never the card number. See tokenisation, encryption and hashing.
  • Never let card numbers into logs, emails, spreadsheets or support tickets. A single stored card number pulls that system into scope. See logging, masking and audit trails.
  • Never record CVV numbers anywhere — storing them after authorisation is prohibited outright.

Your payment provider carries the heavy end of PCI compliance for its own platform, but outsourcing does not remove your obligations entirely: you remain responsible for the parts you control, such as your website's integrity and how your staff handle card details.

What happens if you don't comply?

Non-compliance exposes a business to consequences through its acquiring bank and the card schemes: fines passed down contractually, increased transaction costs, mandatory forensic investigations after a breach, and ultimately loss of the ability to accept cards. After a data breach, the difference between "compliant and breached" and "non-compliant and breached" is significant — and breaches of personal information also trigger South African obligations under POPIA. See KYC, AML, sanctions and POPIA.

Back to Refunds, Disputes, Fraud and Compliance.

Copyright © 2026 Kwik Payments