PCI DSS for small merchants: a plain-English guide

PCI DSS (the Payment Card Industry Data Security Standard) applies to every business that accepts card payments, however small. For most small merchants the easiest path is to never touch card numbers at all: use a hosted payment page, payment link or card machine from a compliant provider, which usually lets you qualify for the shortest self-assessment questionnaire (SAQ A for online, or a short SAQ for approved card terminals).

The standard is maintained by the PCI Security Standards Council; your acquiring bank or payment provider decides how you must validate compliance. The current version is PCI DSS v4.0.1. This guide explains the practical side for South African businesses.

Who has to comply?

Anyone who stores, processes or transmits cardholder data, or whose systems can affect the security of that data. That includes you if you:

• Take card payments online (even through a gateway)
• Use a card machine
• Take card details over the phone
• Charge saved cards for subscriptions

Your provider's agreement almost certainly requires PCI DSS compliance. Non-compliance can lead to fines passed on by the acquirer, higher fees, or liability for fraud losses after a breach.

Which SAQ applies to you?

Small merchants usually complete a Self-Assessment Questionnaire (SAQ) rather than a full audit. The main types:

Your provider will tell you which SAQ they expect. If in doubt, ask them, not a forum.

What changed for SAQ A in 2025

PCI DSS v4.0 introduced new requirements about scripts on payment pages. For SAQ A merchants, the Council later removed requirements 6.4.3 and 11.6.1 from SAQ A (effective 31 March 2025) and replaced them with an eligibility criterion: the merchant must confirm its site is not susceptible to attacks from scripts that could affect its e-commerce system. The PCI Council explains this in an FAQ on SAQ A eligibility.

In plain terms: if you redirect to or embed a provider's payment page, you still need to keep your own website secure, because a compromised site can redirect customers to a fake payment page.

The small-merchant rules that matter most

1. Never store card numbers

Don't write card numbers on paper, in spreadsheets, email, WhatsApp or your CRM. If you need to charge a card again, use your gateway's tokenisation, which gives you a token instead of the card number.

2. Never store CVV codes

The three-digit security code must never be stored after authorisation, by anyone, in any form.

3. Use hosted payment pages or payment links

Letting the provider capture card details keeps your systems out of most of the scope. Payment links are ideal for invoices and phone orders: send the link instead of taking the card over the phone.

4. Secure your website

Keep your CMS, plugins and themes updated, use strong unique passwords with two-factor authentication, remove unused admin accounts and plugins, and monitor for unexpected changes to pages that link to checkout.

5. Protect card terminals

Check devices for tampering, keep them in sight, and only let the provider service them.

6. Train staff

Staff should know never to accept card details by email or chat and to recognise phishing.

7. Complete your SAQ annually

Fill in the questionnaire your provider requires, keep a copy, and repeat each year or when your setup changes.

PCI DSS and POPIA

PCI DSS is an industry standard enforced through contracts; POPIA is law. A card breach is also a security compromise under POPIA, with notification obligations to the Information Regulator. The best way to satisfy both is to minimise the payment data you hold. See POPIA and customer payment data.

Subscription billing without storing cards

Recurring card billing doesn't require you to store cards. The standard pattern is:

1. The customer enters their card on the gateway's hosted page at sign-up.
2. The gateway returns a token.
3. Your billing system charges the token each period.
4. When the card expires or fails, the customer updates it through a hosted page or customer portal.

For many South African recurring businesses, debit orders are also an option. See EFT vs debit order vs card.

How CentraPoint helps

CentraPoint never asks you to handle card numbers: customers pay on your connected gateway's secure page, through hosted checkout pages and payment links, and recurring card billing uses the gateway's tokenisation. That keeps card data out of your systems and typically simplifies your PCI DSS scope (your provider confirms the SAQ). Accounts are protected with roles, permissions and authenticator-app 2FA. See our security page and the gateways docs.

Frequently asked questions

Do small businesses need to be PCI compliant?

Yes. PCI DSS applies to all merchants that accept cards, regardless of size. Small merchants usually validate compliance with a self-assessment questionnaire.

What is SAQ A?

SAQ A is the shortest self-assessment questionnaire, for e-commerce merchants who fully outsource card capture to a PCI-compliant provider's hosted page or iframe and don't store, process or transmit card data on their own systems.

Can I take card details over the phone?

It significantly increases your PCI scope. A safer option is to send the customer a payment link so they enter their card details on the provider's page themselves.

Is it safe to save card details for recurring billing?

Yes, if the card is tokenised by a PCI-compliant gateway and you only store the token. Never store the card number or CVV yourself.