3D Secure 2, chargebacks and fraud rules for South African card payments

They are three layers of the same problem. 3D Secure 2 works before the payment, checking that the person paying is the cardholder. Chargebacks work after it, letting a cardholder reverse a payment through their bank. The rules around both come from the card schemes, your acquirer or PSP, and increasingly the SARB.

Card payments are where all three matter most, and cards are not going anywhere soon: last year PayShap processed only about 6% as many transactions as cards^{[BIS: Kganyago, checked 2026-11-04]}. So for most South African checkouts, card fraud and dispute handling stay a core job, not an edge case. For where cards sit next to EFT, debit orders and PayShap, see how payments work in South Africa.

This page covers the parts that apply whichever PSP you use. Provider-specific dispute handling lives with each provider: for Paystack, the disputes and chargebacks developer playbook walks through the API and webhooks.

Whether the issuing bank believes the cardholder is the one paying. 3D Secure 2, the EMV 3DS protocol, adds an authentication step between your checkout and the card authorisation. Your PSP sends the issuer data about the payment and the device: the amount, the merchant, browser or app details, and whatever customer and order data you pass along. The issuer's risk engine then picks one of three outcomes.

• Frictionless. The data looks right, and the issuer authenticates the payment without involving the customer.
• Challenge. The issuer wants proof, so the customer approves the payment in their banking app or types a one-time PIN.
• Failed or rejected. Authentication did not succeed, and the payment should not go ahead.

The result becomes part of the payment's record, which matters if the cardholder later says they did not make the payment.

The version matters. The first version of 3-D Secure sent customers to a password page on almost every payment. 3D Secure 2 was built for risk-based decisions and for mobile apps, so a well-integrated checkout can pass many payments with no challenge at all. The lever you control is data. Billing and shipping details, email, phone, account age and order history, plus the device data your PSP's script or SDK collects, give the issuer reasons to approve without a challenge. Thin data pushes issuers towards challenges, and every challenge loses some customers.

Through the PSP, in almost every case. There are three integration shapes, and the right one depends on how much of the card form you want to own.

• Hosted checkout or payment page. The PSP runs the whole authentication step and tells you the final status by webhook. The least work and the least control, and the right default for most businesses.
• Your own page with the PSP's card fields or SDK. Card data still goes into the PSP's fields, and the PSP runs 3D Secure for you, but you host the page. You must show the challenge (in a frame or by redirect), handle the customer's return, and wait for the final status.
• Card data through your own servers. Only if you are certified under PCI DSS for it, and then you integrate a 3DS server yourself. Very few South African businesses need this.

Whichever shape you choose, the same failures show up in production:

• The challenge never appears. In-app browsers and some webviews block the challenge frame or the switch to the banking app. Test inside the apps your customers actually use, such as social media and messaging apps that open links internally.
• The customer approves but never comes back. Banking-app approval moves the customer away from your page. Mark the order from the PSP's webhook, never from the return URL alone.
• The approval arrives late. A customer who takes a few minutes in their banking app can succeed after your page has given up. Keep orders pending, not failed, until the PSP says otherwise.
• The customer pays twice. A second click while the challenge is pending starts a second payment. Disable the button and send an idempotency key with every payment request.
• Authentication passes, authorisation fails. A successful challenge followed by a decline for insufficient funds needs its own message, or customers blame your site.

For the gateways themselves, Payfast vs Paystack vs Ozow vs Peach Payments compares fees and developer experience.

It runs backwards through the card chain. In general terms:

1. The cardholder disputes a payment with their bank: they do not recognise it, the goods never arrived, it was charged twice, or a subscription kept billing after they cancelled.
2. The issuing bank raises a chargeback through the card scheme to your acquirer.
3. Your acquirer or PSP takes the disputed amount from your balance or holds it, and asks you for evidence by a deadline.
4. You accept the chargeback, or you submit evidence to contest it.
5. The issuer decides, and some cases go further under the scheme's rules.

Deadlines, reason codes and fees come from the card schemes and your PSP agreement. They differ by scheme and change over time, so this page does not restate them; your PSP's dispute documentation is the source of truth. For the business side, handling a chargeback as a small business covers what to send and how to respond.

Every method can be disputed somehow, but the route and the window differ, and that should shape what you offer.

Who can reverse a South African payment, and how

Payment method	How the payer can reverse it	What it means for you
Card payments	A chargeback raised through the card issuer and the card scheme, under the scheme's rules	Keep evidence for every order; authentication helps only against fraud claims
Ozow pay-by-bank (EFT)	Ozow says its payments involve no credit card chargebacks and no reverse transactions	Lower dispute exposure, which suits digital goods and high-fraud categories
Debit orders, DebiCheck and Registered Mandates	A dispute period of 60 calendar days from 13 April 2026, down from 365 days	Plan refunds, holds and reconciliation around the shorter window

Last verified: 2026-11-05. Sources, checked 2026-11-05: Ozow FAQ, PASA. Card dispute deadlines, reason codes and fees come from the card schemes and your PSP agreement, which this table does not restate.

Push payments, where the payer sends the money, have no card-scheme chargeback behind them. That cuts both ways: no chargebacks for you, but also no reason to treat a customer's screenshot as proof of payment. Confirm every push payment from your bank or PSP. The Ozow explainer covers how its pay-by-bank flow works, and debit orders vs DebiCheck covers the collection side.

If you want card, pay-by-bank and recurring flows built with disputes in mind from day one, Mctaba Labs payment integration builds those integrations on South African rails.

The SARB is moving into fraud directly. The SARB has released a draft Fraud Risk Framework^{[SARB Annual Report 2025/26, checked 2026-11-05]}, and what the draft means for merchants and PSPs goes through it, and the SARB's modernisation programme covers the other reforms running alongside it. Until it is final, the rules you work under day to day are the card schemes' and your acquirer's.

The SARB has shaped card economics before, and the history is useful context. Its interchange determination implemented on 16 March 2015 set 0.44% for debit and 1.48% for credit on card-present purchases where both issuer and acquirer are EMV compliant; other transaction types carry different rates^{[SARB, checked 2026-11-05]}. Two lessons follow. The determination tied its headline rates to chip (EMV) compliance on both sides, so security and cost were linked in how the SARB approached cards. And it is a historical determination for card-present purchases, not a rate card for online payments today, so do not use it to estimate what your PSP charges.

Mostly by design choices made before the first dispute arrives.

• Offer pay-by-bank next to cards for risky products. Digital goods, vouchers, tickets and anything resold quickly attract card fraud. Giving customers an EFT or pay-by-bank option moves part of that volume off the chargeback route.
• Make the charge recognisable. A billing descriptor the customer recognises, an emailed receipt and an easy cancellation path for subscriptions prevent the "I don't recognise this" disputes that are not fraud at all.
• Refund before the dispute. When a customer complains, a refund costs you the sale. A lost chargeback costs you the sale, the goods and usually a fee on top.
• Capture evidence at payment time. Store the authentication result, IP address, device data, delivery confirmation, the terms the customer accepted and every message exchanged, keyed to the order. Assembling it after the dispute arrives is too slow.
• Limit attempts. Cap payment attempts per card, device and account, and slow down repeated declines; card-testing bots look exactly like that.
• Watch the rate. Track disputes per product and per payment method every week. A rising rate is the earliest warning you get.

For recurring card billing, card tokenisation and subscription billing covers how stored cards are charged, and recurring payments in South Africa compares card tokens with DebiCheck and Capitec Pay VRP. For the rest of the region, see payments in Southern Africa.

When you would rather have the checkout, the webhooks and the evidence trail built for you, Mctaba Labs payment integration works on exactly these South African systems.