Skip to main content
CentraPoint

POPIA payment data compliance: a practical guide for merchants

How POPIA applies to payment data: what counts as personal information, security safeguards, operators, breach reporting and cross-border transfers for SA merchants.

Published
Reading time
7 min read
By
CentraPoint Team
On this page
  1. What counts as payment data under POPIA
  2. The conditions that matter most for payments
  3. Practical safeguards for payment data
  4. Breach reporting: what to do
  5. Cross-border processing
  6. A POPIA payment data checklist
  7. How CentraPoint helps
  8. Frequently asked questions

Under POPIA, payment data that identifies a person, such as a customer's name linked to their bank account number, card details, transaction history or billing address, is personal information, and your business is responsible for processing it lawfully and keeping it secure. In practice that means collecting only what you need, protecting it with appropriate technical and organisational measures, holding your service providers to the same standard by written contract, and reporting security compromises to the Information Regulator and affected customers as soon as reasonably possible.

This guide explains how the Protection of Personal Information Act applies to everyday payment processes. It's general information, not legal advice; speak to a qualified adviser about your specific situation.

What counts as payment data under POPIA

POPIA protects personal information about identifiable, living natural persons and, unusually, existing juristic persons such as companies. In a payment context that commonly includes:

Data Example
Identity and contact details Name, email, cellphone number, billing address
Account and card details Bank account number, branch code, card number or token
Transaction history What someone bought, when and for how much
Mandate information Debit order mandates and their authentication records
Identifiers ID number, VAT number, customer reference

The Act defines personal information broadly and specifically lists identifying numbers and financial history, so treat everything in your billing system as in scope.

The conditions that matter most for payments

POPIA sets out conditions for lawful processing. For payments, these are the ones that usually drive decisions:

Minimality and purpose

Collect only what you need for the payment and related obligations such as tax invoices and record-keeping. If you use a gateway's hosted checkout, you may never need to see a full card number at all, which removes a large category of risk.

Retention

Keep records for as long as the law or your legitimate purpose requires (tax and accounting rules often set minimum periods), then delete or de-identify them. Don't keep old card exports or bank detail spreadsheets "just in case".

Openness

Tell customers what you collect, why and who you share it with (for example your payment gateway or debit order provider) in your privacy notice.

Security safeguards (sections 19 to 22)

This is where payment data gets the most attention:

  • Section 19 requires appropriate, reasonable technical and organisational measures to prevent loss, damage, unauthorised destruction and unlawful access. You must identify risks, put safeguards in place, check they work and update them as risks change.
  • Sections 20 and 21 deal with operators: anyone processing personal information on your behalf, such as a payment gateway, billing platform, hosting provider or bookkeeper. You need a written contract requiring them to maintain security measures and to notify you of breaches.
  • Section 22 requires notifying the Information Regulator and affected data subjects of a security compromise as soon as reasonably possible.

Practical safeguards for payment data

A realistic baseline for a South African merchant:

  1. Keep card data off your systems. Use hosted payment pages or provider-hosted fields so raw card numbers go straight to the gateway. PCI DSS still applies to card acceptance; check your obligations with your acquirer.
  2. Encrypt sensitive data at rest and in transit. HTTPS everywhere; encryption for stored bank details and credentials.
  3. Limit access. Give staff only the access they need, and review it when roles change. See role-based access control for finance teams.
  4. Require two-factor authentication on every system that holds customer or payment data.
  5. Protect API keys and credentials, and rotate them when people leave.
  6. Log and monitor. Keep audit logs of who viewed, exported or changed sensitive data.
  7. Secure exports. Spreadsheets of customer bank details emailed around the office are one of the most common weak points.
  8. Train staff to recognise phishing and requests to change bank details.

Breach reporting: what to do

If you suspect a security compromise involving personal information:

  1. Contain it. Revoke credentials, isolate affected systems, stop the leak.
  2. Assess it. What data, how many people, how likely is misuse?
  3. Notify the Information Regulator as soon as reasonably possible. As of September 2026, security compromise notifications must be submitted through the Regulator's eServices portal (required since 1 April 2025); check the Information Regulator's website for the current process.
  4. Notify affected data subjects as soon as reasonably possible, with enough information for them to protect themselves, unless the Regulator or law enforcement directs a delay.
  5. Record everything and fix the root cause.

The Act allows administrative fines of up to R10 million, alongside other enforcement measures, so preparation is worth the effort.

Cross-border processing

Many payment and SaaS tools store data outside South Africa. Section 72 restricts transferring personal information to a third party in a foreign country unless conditions are met, such as the recipient being bound by law, corporate rules or an agreement providing adequate protection, the data subject consenting, or the transfer being necessary for a contract. Ask each provider where data is stored and what protections apply, and document the answer.

A POPIA payment data checklist

  • Information officer registered and privacy notice up to date
  • Map of where payment data lives, including exports and backups
  • Hosted checkout so card numbers never touch your servers
  • Written operator agreements with gateways and software vendors
  • Access limited by role, with 2FA and audit logs
  • Retention periods defined and old data deleted
  • Breach response plan, including Regulator eServices notification
  • Cross-border transfers identified and justified

How CentraPoint helps

CentraPoint is designed to reduce the payment data you handle directly. Card payments run through the gateways you contract with, using their hosted or tokenised flows; gateway credentials are encrypted at rest with AES-256-GCM; and access is controlled with roles and permissions, authenticator-app 2FA and audit logs. Customers can view invoices and download receipts through a self-service portal rather than by email attachments. The security page has more detail.

Frequently asked questions

Does POPIA apply to card and bank account details?

Yes. Account numbers and financial information linked to an identifiable person or existing company are personal information, so they must be processed lawfully and secured.

Is my payment gateway responsible for POPIA compliance?

The gateway has its own obligations, but when it processes data on your behalf you remain the responsible party. You need a written agreement that requires it to secure the data and notify you of breaches.

How do I report a data breach under POPIA?

Notify the Information Regulator through its eServices portal and inform affected people as soon as reasonably possible. Check the Regulator's website for the current forms and guidance.

What is the maximum POPIA fine?

The Information Regulator can impose administrative fines of up to R10 million, and serious offences can also lead to criminal penalties.

  • #popia
  • #compliance
  • #data protection
  • #security