3-D Secure for online card payments, explained
What 3-D Secure checks when a customer pays you by card online, what it asks of the customer, who decides when it appears, and how pay links fit in.
By Achekam · · 5 min read · For Running a business businesses in South Africa, Nigeria, Kenya
When a customer pays in your shop, they hold the card, and the terminal reads the chip. When they pay from a link on their phone at midnight, nobody sees the card at all. That gap is where most online card fraud lives, and it is the gap 3-D Secure was built to close.
If you send invoices with a pay link, or take card payments through a gateway such as Paystack, Flutterwave or Stripe, your customers will meet 3-D Secure sooner or later: a one-time PIN by SMS, a prompt in their banking app, or sometimes nothing visible at all. Knowing what is happening behind that screen helps you answer the customer who rings to ask why their bank "stopped" the payment.
The problem it solves: card-not-present fraud
A payment where the card is not physically presented to the merchant is called card-not-present. Someone who has stolen card numbers can try them on any website without holding the plastic.
EMVCo, the body that maintains the specification, says card issuers and merchants use EMV 3-D Secure (3DS) to authenticate consumers and to safeguard against card-not-present fraud. In plain terms, 3DS gives the bank that issued the card a chance to ask, "Is this really our customer?" before the payment goes through.
What the customer's bank gets to see
The useful part of 3DS is the information it carries. EMVCo explains that EMV 3DS exchanges data between the merchant and the card issuer, including details about the transaction, the payment method and the device being used, so the issuer can authenticate the consumer and approve the transaction.
Picture a Nairobi customer settling a shilling invoice for a monthly service. The bank sees the amount, the merchant, the card and the phone the payment comes from. If that phone and that pattern look like the customer's usual behaviour, the bank may let the payment through quietly. If something looks wrong, such as a new device or an odd amount, it may step in and ask the customer to prove who they are.
Friction, and why customers abandon payments
Every extra step at checkout is a chance for a customer to give up. A one-time PIN that arrives late, a banking app that will not open, or a screen the customer does not recognise can each end a sale.
EMVCo addresses this directly. It says the data exchanged through EMV 3DS lets issuers identify and prevent fraudulent transactions without adding unnecessary friction, which it notes often leads to abandoned purchases. EMVCo also publishes EMV 3DS UI/UX design guidelines to help issuers, merchants and solution providers improve the authentication experience for online shoppers.
What this means for you:
- Expect some customers to be challenged and others not, even for similar amounts.
- Tell customers in your invoice e-mail that their bank may ask them to confirm the payment.
- When a customer says the payment "failed", ask whether they received a prompt from their bank before assuming the link is broken.
- Keep your business name recognisable on the pay page, so a customer who is challenged knows who they are paying.
Who decides when 3DS is asked for
It is tempting to think the business switches 3DS on or off. In practice, the decision is shared. Writing about subscription card payments, Stripe states that whether a payment needs 3D Secure authentication depends on the merchant's fraud rules and on the card's issuing bank.
So there are at least two voices: the fraud settings your payment provider applies to your account, and the customer's bank, which may require authentication regardless. Your gateway's own documentation and dashboard are the place to see what rules apply to your account; ask your provider if anything is unclear.
A short table of who does what:
| Party | Role in 3-D Secure |
|---|---|
| Customer | Confirms the payment when the bank asks, by PIN, app or other method |
| Card issuer (customer's bank) | Reviews the data and decides whether to challenge or approve |
| Payment gateway | Runs the checkout and applies the fraud rules set for your account |
| Your business | Chooses the gateway, keeps its settings sensible and explains the process to customers |
Pay links and the gateways Achekam connects to
In Achekam, a business can create a payment link for an issued customer invoice, copy it or e-mail it with the invoice, and the customer pays on a public page that shows the business's name and branding. A link cannot be made for a draft or voided invoice.
The link works through the business's own gateway. A workspace administrator enters the gateway credentials in Settings under Payment Gateways & Checkout and can test the connection with a real call to the gateway. Among the options:
- Paystack, for invoices in NGN, KES, GHS, ZAR or USD, with each payment confirmed with Paystack before it is recorded.
- Flutterwave, for invoices in ZAR, NGN, KES, GHS or USD, with each payment re-verified with Flutterwave before it is recorded.
- Stripe Checkout, in ZAR, USD, EUR or GBP, with webhooks accepted only when their signature is valid and recent.
The authentication step itself belongs to the gateway and the customer's bank. What Achekam adds is what happens after the money moves: a verified gateway payment is recorded as a receipt against the invoice, debiting that gateway's clearing account and crediting trade receivables, and the invoice shows as paid or part-paid. The invoice, the receipt and the ledger entry stay together, so nobody has to retype the payment.
Achekam never charges a customer automatically. There are no saved cards or debit orders, so every card payment is one the customer starts and completes on the pay page. For the wider card-security picture, see our guide to PCI DSS levels and what a small merchant validates.
When authentication is not enough
3DS makes it harder for a stranger to use a stolen card. It does not stop a genuine customer from disputing a charge later because the goods never arrived or the service was not what they expected. That is a separate process with its own deadlines, covered in what happens when a customer disputes a card payment.
EMVCo's own overview of EMV 3-D Secure explains how issuers and merchants use it against card-not-present fraud and links to the design guidelines. Read it once, then ask your gateway provider how 3DS is applied to your account, and put a line about bank confirmation in the e-mail that carries your pay links.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
