Fraud prevention and Strong Customer Authentication

A fraudulent charge — a stolen card used to buy something, with the real cardholder never having authorized it — eventually surfaces as a dispute (the previous lesson's chargeback), at which point the merchant has already lost the goods, the payment, and a dispute fee. Two mechanisms exist specifically to catch this before the charge succeeds, working in fundamentally different ways: statistical risk scoring, and mandatory customer authentication.

A payment gateway (and increasingly, additional dedicated fraud tools) score each transaction against dozens of signals — device fingerprint, IP geolocation versus the billing address, velocity (many attempts in a short window), whether this card has been seen failing on other merchants recently — and return a risk score the merchant's own logic can act on:

This is inherently probabilistic — a risk score is a bet, not a certainty, and both failure directions have a real cost: too aggressive, and legitimate customers get blocked or annoyed with extra friction (lost revenue, a bad experience); too permissive, and fraudulent charges slip through to become disputes later. Tuning this threshold is an ongoing operational job, not a one-time configuration.

SCA (mandated in the EU/UK under PSD2, and increasingly expected elsewhere) takes a different approach for a defined category of transactions: instead of guessing whether a charge is legitimate, it requires the customer to prove it directly, using at least two of three factor categories — something they know (a PIN), something they have (a phone receiving an SMS code, a banking app), something they are (biometrics).

3D Secure (3DS) is the specific protocol that implements this for card payments — the "Verified by Visa" / "Mastercard Identity Check" prompt that redirects a customer to their bank to confirm the charge:

A charge that completes 3DS authentication successfully shifts fraud liability to the issuing bank — if it later turns out to be fraudulent anyway, the bank (not the merchant) typically absorbs the dispute cost. This is a distinct, separate benefit from the security itself: a merchant processing many transactions has a real financial incentive to route eligible transactions through 3DS specifically because of this liability shift, not purely out of caution.

3DS adds a real step to checkout — a redirect, a wait, a chance for a customer to abandon the purchase partway through. Regulations exempting low-risk or low-value transactions from mandatory SCA exist precisely because blanket-requiring it everywhere would meaningfully hurt conversion for the large share of transactions that were never actually going to be fraudulent. Many gateways support exemptions (low-value transactions, recognized recurring subscriptions, merchant-classified low-risk transactions) that skip the 3DS challenge while still completing the underlying payment — the same score-versus-certainty trade-off from risk scoring, applied to when to invoke a stronger, more disruptive check.

Fraud prevention and SCA sit upstream of almost everything else covered here: a charge that clears both checks still goes through the same webhook-driven, idempotent, signature-verified flow (lessons 2, 5, 6) as any other payment, and a fraudulent charge that does slip through still surfaces exactly as the previous lesson described — as a dispute, pulling funds back immediately and requiring the merchant to respond with evidence.