3D Secure and how it affects conversion

4 min read

Quick answer #

3D Secure (3DS) is an extra authentication step that asks the customer to confirm a card payment through their bank — usually via OTP, banking app, or biometric. Pay@ Gateway uses 3D Secure 2.0 on all card transactions because it’s a regulatory requirement in South Africa and shifts liability for fraudulent transactions from the merchant to the card issuer. 3DS adds a step to checkout, which can reduce conversion by 2–5%, but 3DS 2.0’s smarter risk-based flow makes that drop much smaller than the older 3DS 1.0.

What 3D Secure actually does #

When a customer enters their card details at checkout, three things happen:

The transaction is submitted to the card network (Visa or Mastercard)
The card network asks the customer’s bank: “is this transaction risky?”
The bank decides to either silently approve, or trigger a 3DS challenge

If a challenge is triggered, the customer is briefly redirected to their bank’s authentication page, where they confirm the transaction by OTP, push notification, biometric, or banking-app approval. After confirming, they’re returned to your checkout and the payment completes.

The 3DS step typically takes 10–60 seconds depending on how the customer authenticates.

Why 3DS 2.0 is dramatically better than 3DS 1.0 #

The original 3D Secure (rolled out in the early 2000s) was a nightmare for conversion. It challenged almost every transaction with a clunky popup, and customers regularly dropped off or had failed authentication.

3D Secure 2.0 is fundamentally different:

Risk-based authentication. Banks now use 100+ data signals to decide whether to challenge. Low-risk transactions (a regular customer buying their usual amount from their usual device) pass through silently — no popup, no OTP, no friction.
Frictionless flow. When no challenge is needed, the customer doesn’t even know 3DS happened.
Better authentication options. When a challenge is needed, the bank can use the customer’s banking app rather than SMS OTP — much faster and more reliable.
Mobile-optimised. The challenge flow works properly on mobile (3DS 1.0 was notoriously broken on phones).

Industry data suggests around 70–85% of 3DS 2.0 transactions complete frictionless, without a challenge. The 15–30% that do get challenged are the ones the bank’s risk engine genuinely flagged.

Why South Africa requires 3DS #

3D Secure is mandatory for online card transactions in South Africa under SARB regulations. This is non-negotiable — no SA gateway can disable 3DS on card payments, including Pay@. The regulation exists because chargeback fraud is high in card-not-present transactions, and 3DS materially reduces it.

The flip side of the regulation: when 3DS completes successfully, the liability for fraudulent transactions shifts from the merchant to the card issuer. This means if a customer disputes a charge claiming “I didn’t make that payment”, and you have proof that 3DS authentication succeeded, the card issuer absorbs the chargeback, not you.

This is a meaningful financial benefit. For most merchants, 3DS saves significantly more in prevented chargebacks than it costs in slightly reduced conversion.

The conversion impact, honestly #

3DS does reduce conversion. The impact varies by:

Industry. High-risk categories (digital goods, gambling, travel) see more challenges and bigger drops.
Transaction size. Larger transactions are challenged more often.
Customer behaviour. Customers buying from a new device, new IP, or new location see more challenges.
Time of day. Late-night transactions occasionally trigger more risk flags.

Typical conversion impact on a well-implemented 3DS 2.0 flow: 2–5% reduction compared to no 3DS. Compared to the old 3DS 1.0: 3DS 2.0 recovers most of the lost conversion.

You can’t legally turn 3DS off in South Africa, so this is academic — but if you’re benchmarking against international gateways or older comparison data, factor it in.

What you can do to maximise conversion #

Things within your control:

Use Pay@’s hosted checkout — it’s optimised for 3DS 2.0 with mobile-first UX and proper error handling.
Don’t redirect the customer multiple times. Each redirect compounds drop-off.
Pass strong transaction context (cart contents, customer email, billing address) through the API — this helps the bank’s risk engine recognise legitimate transactions and skip the challenge.
Pre-fill customer details on returning visitors so the bank sees a familiar device + customer pattern.