Data Protection for Payments in South Africa

What counts as personal information in a payment-

Under POPIA, personal information concerns identifiable living people and, where applicable, existing juristic persons. A bank account number, card detail or email address can identify someone directly or through a linked order. The privacy obligation extends to that link.

A transaction reference and the last four card digits are not equivalent to a full primary account number (PAN) or CVV. They may still be personal information when tied to a named customer. Keeping the PAN out of the shop's database reduces card-data exposure; it does not settle POPIA compliance.

Where payment data goes after a customer selects Pay

In a card purchase, the merchant creates the order. A payment gateway captures or routes the payment, a processor and acquiring bank support its passage through a card network such as Visa or Mastercard, and the issuing bank decides whether to authorise it. EMV 3-D Secure may add cardholder authentication along the way. The precise flow depends on the provider and integration.

1. Checkout: The customer enters contact and order information. Card details are entered on a provider-hosted payment page, a hosted field or a merchant-controlled form, according to the integration.
2. Authentication and authorisation: The issuing bank may authenticate the cardholder using an app approval, biometric verification or one-time password (OTP). The bank approves or declines the payment separately from the merchant's order acceptance.
3. Confirmation and settlement: A payment reference and transaction status reach the merchant. Reconciliation and settlement records can remain in the merchant's accounting or customer-support systems after the card interaction ends.
4. Later processing: Refunds, chargebacks, subscriptions, customer queries and tax records create additional uses and storage locations for transaction information.

Take an R850 order paid through a provider-hosted checkout. The gateway receives the card details; the shop keeps the customer's name, delivery address, order amount and payment reference. PCI DSS compliance at the gateway does not protect the shop's exported orders or staff accounts.

Electronic funds transfers (EFT), pay-by-bank payments, debit orders and payment links avoid some card-specific risks. They still leave banking details, mandates and customer records that need protection.

What POPIA requires from South African businesses

POPIA sets eight conditions for lawful processing. They also cover records kept after the sale.

Consent is not the only lawful basis for processing a payment

Consent is one lawful ground, not the default answer to every payment. POPIA also provides grounds related to performing a contract, meeting a legal obligation and qualifying legitimate interests. A business charging for an agreed order should identify the ground that actually fits, rather than use a marketing consent checkbox to justify routine billing.

Marketing changes the purpose. POPIA restricts unsolicited electronic direct marketing, with a limited exception for existing customers receiving offers for the supplier's own similar products or services, subject to an opportunity to object. The 2025 amended regulations clarified that an opt-out mechanism is not consent. A checkout record should not silently become a promotional mailing list.

Who is responsible: the merchant or the payment gateway-

Under POPIA, the responsible party decides why and how personal information is processed. An operator processes it on that party's behalf. A gateway may be an operator for one activity and have separate responsibilities for another. Its actual role depends on the service and contract, not its marketing description.

Sections 20 and 21 require confidentiality and appropriate safeguards in operator arrangements. Where an operator processes information for a responsible party, a written contract must require suitable security measures. An operator must notify the responsible party immediately when there are reasonable grounds to believe that an unauthorised person accessed or acquired personal information. Merchant accountability remains for its website, customer database and refund processes.

POPIA, PCI DSS and Payment Rules

PCI DSS is an industry standard, not a South African privacy statute. The PCI Security Standards Council maintains it; card schemes and acquirers set the applicable compliance programmes. PCI DSS v4.0.1 covers controls including payment-page security, access, monitoring and vulnerability management. A processor's Level 1 assessment does not automatically certify the merchant's own website.

The South African Reserve Bank (SARB), through its National Payment System Department, oversees payment-system safety and stability. The Payments Association of South Africa (PASA), banks and card schemes have distinct roles. POPIA compliance remains within the Information Regulator's remit.

Choosing a payment integration changes the security workload

Checkout design changes both the security exposure and the PCI DSS work. A WooCommerce or Shopify store that redirects customers to a provider handles card data differently from a custom checkout that captures card numbers itself. Recurring billing introduces another decision: where the reusable payment credential will be held.

Outsourcing card entry does not automatically remove every PCI DSS duty. The PCI Security Standards Council's SAQ A guidance distinguishes redirects from embedded third-party forms and explains the relevance of malicious scripts on the merchant's page. Eligibility must match the actual integration, not a generic claim that the gateway is compliant.

What 3D Secure Does Not Protect

EMV 3-D Secure (3DS) lets an issuing bank authenticate a cardholder, sometimes through an app approval, biometrics or a one-time password (OTP). Payfast, Peach Payments and Yoco describe 3DS in their South African card-payment arrangements. The issuer determines the authentication step.

3DS can reduce unauthorised-card-use risk and may affect chargeback liability under card-scheme rules. It cannot verify that a seller is genuine, secure a customer database or stop an altered EFT invoice. An unexpected request for an OTP or banking-app approval remains suspicious, even when the caller claims to be from a bank.

Encryption, tokenisation and masking protect different things

• TLS/HTTPS protects information while it travels between a browser and a server. A padlock does not verify the honesty of a merchant or the security of everything behind the website.
• Encryption at rest protects stored data when implemented with sound key management. An attacker with access to the application and its keys might still be able to recover the information.
• Tokenisation substitutes a reference value for a sensitive payment credential. The provider maps that token to the underlying credential under controlled conditions, which can support recurring transactions without exposing the raw card number to the merchant.
• Masking hides parts of a card number when displayed in an interface or receipt. Hiding digits on a screen is not a substitute for securing a database containing full numbers.
• Point-to-point encryption (P2PE) protects eligible payment data from an approved point of interaction through to a controlled decryption environment; its scope and deployment must be checked rather than assumed for every card machine.

PCI DSS prohibits retaining CVV/CVC, full track data and PIN-related sensitive authentication data after authorisation, even if encrypted. For repeat payments, a correctly configured provider-managed token or recurring-payment service avoids keeping those credentials in a merchant spreadsheet.

Where secure checkout still leaves gaps

Fake proof of payment and altered bank details

EFT fraud often bypasses card controls altogether. A convincing PDF proof of payment does not show that funds have cleared. Nor should an email announcing changed supplier banking details be trusted on its own. Confirm the payment in the bank or trusted dashboard before dispatch, and verify changed beneficiary details through an established contact channel.

Phishing, SIM swaps and account takeover

Cloned payment pages and support messages can trick people into disclosing credentials, card numbers or OTPs. Criminals may also use SIM swaps to compromise SMS-based checks. Staff accounts merit multi-factor authentication (MFA), ideally phishing-resistant where supported. Customers can compare unexpected banking-app prompts with the transaction they actually initiated.

Malicious checkout scripts and vulnerable plugins

With e-skimming, malicious JavaScript captures information in the browser before the legitimate processor receives it. Tag managers, advertising code and vulnerable plugins can provide an entry point. PCI SSC guidance on payment-page security addresses script authorisation, integrity checks and tamper detection. The merchant's obligations depend on its checkout and assessment scope.

Unprotected exports, refunds and customer support

Consider three routine failures: a finance export contains hundreds of customers' bank details, support requests a card photograph over WhatsApp, or a single employee can redirect a refund to a new account. None is cured by the gateway's certification. Limit exports, use approved communication channels and require separate checks for unusual refunds or account changes.

False positives in fraud screening

Fraud screening compares signals such as transaction value, device information and billing or delivery mismatches. Overblocking costs legitimate sales; loose controls invite chargebacks. Merchants need review criteria, records of overrides and limits on who can approve exceptions. Profiling and automated decisions involving personal information also require scrutiny under POPIA.

Data protection controls a South African merchant can verify

A useful security test follows one payment record: where did it enter, who could export it, why was it retained and how will it be deleted- A policy alone does not show who had access.

1. Map the data. Record which information enters checkout, customer relationship management (CRM), accounting software, email, chat tools, backups and payment APIs. Identify who can download or modify it and where each copy is stored.
2. Reduce exposure. Use hosted card-entry solutions where suitable, avoid storing full PAN or other unnecessary identifiers, and keep CVV and PIN data out of post-authorisation systems.
3. Control staff access. Apply role-based access control (RBAC) and least-privilege permissions. Require MFA for payment dashboards, email and privileged accounts. Remove access promptly when staff or contractors leave.
4. Protect the technical environment. Maintain security patches, malware protection, endpoint controls, encrypted backups, secure API keys and secret rotation. Log sensitive exports, refund changes, failed logins and administrative actions.
5. Review suppliers. Document payment gateway, web-hosting, cloud-storage and billing vendors. Check written operator agreements, subcontractors, incident-notification terms, data locations and the provider's relevant PCI DSS Attestation of Compliance (AOC), where applicable.
6. Set retention rules. Keep invoices, accounting records and transaction evidence for the period required by applicable law or a legitimate purpose, then delete or de-identify data when retention is no longer justified. Do not apply an arbitrary universal deletion deadline to tax or dispute records.
7. Publish a usable privacy notice. Identify collection purposes, recipients, security measures at an appropriate level, relevant cross-border handling, contact details and data-subject rights. Separate the payment necessity from optional marketing preferences.
8. Test the response process. Maintain named incident owners, a route for the payment provider to report security concerns, tested backups, evidence-preservation steps and a current notification procedure.

POPIA and the Promotion of Access to Information Act (PAIA) assign duties to an Information Officer. Registration and related compliance procedures should be checked against the Information Regulator's current guidance. A privacy notice is of little use if staff cannot locate or correct the records it describes.

Can South African payment data be stored overseas-

South African businesses frequently use overseas cloud hosting or fraud platforms. POPIA does not require all personal information to stay on South African servers. Under Section 72 , transfers to third parties in other countries need a permitted basis, which can involve adequate protection, binding corporate rules or agreements, relevant consent, or specified contractual necessity.

The relevant questions are where data goes, whether a vendor transfers it onward and which safeguard supports each transfer. Backups, support tools and fraud-screening subcontractors count in that review. A local data-centre address says little about access from abroad. A provider unable to explain its transfers leaves a material gap in the merchant's assessment.

What happens after a data breach or unauthorised payment-

A compromise might be a stolen login, a misdirected spreadsheet, a lost laptop or an attacker taking payment records. First establish whether someone unlawfully accessed or acquired personal information; that determines the POPIA response.

For businesses holding affected personal information

1. Contain the incident. Disable compromised accounts and API keys, isolate affected systems, stop unauthorised exports and preserve relevant logs. Preserve evidence needed to review the incident.
2. Establish the scope. Identify data types, affected customers, time period, vendors and possible misuse. Coordinate with the processor or operator without treating its incident report as a substitute for the responsible party's duties.
3. Notify as required by POPIA. Section 22 requires notification to the Information Regulator and affected data subjects as soon as reasonably possible when the statutory conditions are met, subject to permitted delays involving law enforcement or the Regulator. The Regulator's security-compromise fact sheet states that there is no general low-risk reporting exemption. It also allows initial reporting before every detail is known, followed by updates.
4. Give people usable facts. Communicate the nature of the compromise, possible consequences and protective measures using an appropriate notification channel. Record decisions, notices, incident reviews and corrective action.
5. Repair and verify. Address the exploited weakness, review service-provider access and test whether controls prevent the same type of breach from recurring.

POPIA does not establish a universal 72-hour breach-notification deadline. Section 22 uses an “as soon as reasonably possible” standard when its notification conditions apply, subject to permitted delays. Other sector-specific reporting duties may run alongside it.

For a customer who finds a suspicious transaction

Use the bank's app or the number printed on the card to report a suspicious charge; do not rely on a link in the message that raised the alarm. Freeze the card or account where the bank permits it, dispute the transaction, change exposed credentials and keep dates, screenshots and references. A complaint about personal information and a disputed debit are separate processes.

How to Assess Payment Data Protection

Payfast, Peach Payments, Yoco and FNB describe security features in their public material. Those descriptions do not establish how any particular merchant configured its checkout or whether the merchant controls its own records. The evidence lies in the actual data flow, contracts and current assessment scope.

Data protection questions South African customers and merchants ask

Does POPIA apply to EFT payments without a card number-

Yes. EFT payer identities, bank details, debit-order mandates and transaction histories can be personal information. PCI DSS addresses card account data; POPIA reaches beyond cards.

Does HTTPS prove that an online shop is safe-

No. HTTPS encrypts the browser connection, but fraudulent websites can also use it. A legitimate store may still expose invoices through weak plugins or compromised employee accounts.

Can a store save a customer's CVV for future payments-

No. PCI DSS forbids storing CVV/CVC after authorisation, including encrypted copies. Properly configured tokenisation can support future payments without keeping the CVV.

Does using a payment gateway make a business POPIA compliant-

No. The gateway may handle card details securely while the merchant retains names, orders and refund records. POPIA still applies to the information the merchant controls.

Can customers demand that every payment record be erased-

Not always. A valid deletion request does not override every recordkeeping duty or lawful retention ground. The business must restrict retained information to its justified purpose.