Layering 3DS, Risk and Chargebacks: Get the Order Wrong and All Three Underperform
3-D Secure authentication, transaction risk and chargeback handling are often treated as three independent workstreams owned by three different people, each optimising in isolation. The result: risk tightens thresholds and authentication approval rates fall; a challenge is added and conversion falls; the chargeback ratio does not improve, because the transactions being blocked are legitimate customers while the real problems return through another route.
These three are not parallel. They are three stages of one decision chain, and their order, who holds the final say, and the log they share matter far more than tuning any single layer's parameters.
1. What each layer does
1.1 Risk: should this be allowed
Risk decides before authorization: allow, decline, or demand additional verification. Signals include device fingerprint, behavioural trace, IP and address consistency, account history, and card-range and email characteristics.
The important distinction is granularity. Transaction-level risk answers "does this transaction look fraudulent" and suits guest checkout. Identity-level risk answers "who is this person" and suits businesses with accounts, because account-level signals accumulate across orders and the cold-start problem is fundamentally different. Forcing identity signals into a transaction-level model typically shows up as returning customers being blocked repeatedly while new customers sail through.
Risk produces a probability, not a verdict. It cannot guarantee the block is correct, only that it is justified - which is why the decision log matters more than the threshold.
1.2 Authentication: shifting liability at the cost of drop-off
3DS is a chain: merchant or acquirer to the 3DS Server, to the scheme Directory Server, to the issuer ACS, and back to the merchant. The merchant usually only touches the 3DS Server directly; the rest is decided by the acquiring bank, the scheme and the issuer.
It has exactly two outcomes: frictionless, which passes straight through, or challenge, which asks the user to complete a verification step. The frictionless share is decided jointly by the issuer's risk model and local regulatory exemptions - low-value, transaction risk analysis, trusted beneficiary and merchant-initiated transaction are the familiar exemption families, but whether a given transaction qualifies is the issuer's call. Merchants can influence it, not decide it.
1.3 Chargebacks: the second battle after success
A chargeback is a dispute the cardholder raises with the issuer, with its own deadlines, evidence format and cost structure. This layer has to obtain evidence inside the deadline, organise it by reason code, submit representment, track the outcome, and book losses correctly when it fails.
Chargeback reason codes fall broadly into two families: fraud (the cardholder claims the transaction was unauthorized) and non-fraud (goods not received, not as described, duplicate charge, subscription not cancelled). The countermeasures are entirely different, and looking at a combined total produces the wrong conclusion.
2. The correct order: risk, then authentication, then authorization, then disputes
The sequence is set by mechanism, not by design preference.
Risk expresses a preference first, deciding whether the transaction needs stronger verification. A high-risk transaction waved through means every later stage is serving a transaction that may not be worth serving.
Authentication precedes authorization because it happens at the issuer and travels the scheme chain. Reversing the order does not work technically.
Authorization precedes clearing, and clearing precedes the dispute window. Chargebacks always come last and deal with whatever went wrong earlier.
Three practical conclusions follow.
First, risk should not re-judge after authentication. Blocking a user who has just passed a challenge tells them verifying was pointless, and that experience loss is harder to recover than a chargeback.
Second, an abandoned challenge is not fraud. Users drop out because the page was slow, the banking app failed, or they simply changed their mind. Recording it as a fraud signal poisons the model.
Third, chargeback data must flow back into risk. A chargeback is the only label that confirms a transaction really was fraud. Without the feedback loop, the risk model only ever has front-end guesses and never a back-end verdict.
3. Why frictionless rates fight with risk models
This is the most commonly overlooked conflict among the three layers.
Risk aims to reduce losses; authentication aims to shift liability while preserving approval rates. When risk flags a segment as high-risk and pushes it to a challenge, it looks protective. But the challenge itself drops real users, and any transaction that completes a challenge has already shifted liability to the issuer - meaning the challenged segment is no longer risk's responsibility even if it really was fraud.
The counter-intuitive conclusion: for transactions that can shift liability through authentication, adding another risk block buys very little and costs a lot. Risk should concentrate on what authentication cannot cover - frictionless transactions, merchant-initiated transactions such as subscription charges and billing retries, and payment methods that never travel the card scheme chain at all.
The test is straightforward: split chargebacks by whether a challenge occurred. If challenged transactions still produce a large share of fraud chargebacks, the problem is in the authentication chain, not risk. If frictionless transactions produce most of the fraud loss, the problem is the risk model, not authentication.
4. The real preconditions for liability shift
"Turn on 3DS and fraud chargebacks move to the issuer" is a common oversimplification. Liability shift generally requires several conditions at once, and missing one voids it.
Authentication genuinely completed. The user must verify at the issuer, not merely be redirected through a nominal hop on the merchant side.
Amount and transaction elements match. The amount and currency authenticated must match what is submitted for clearing; partial capture, added tips, or currency conversion that changes the amount can invalidate the shift.
The issuer participates in the system. Not every issuer, card type or region supports liability shift, and cross-border transactions make this especially visible.
The dispute is a fraud dispute. Liability shift covers unauthorized-transaction claims only. Goods-not-received and not-as-described disputes remain the merchant's responsibility.
These four conditions define 3DS as a tool for part of the risk, not all of it. Treating it as a blanket shield leads to heavy losses on goods-not-received disputes.
5. Deriving the three-layer combination from chargeback structure
Do not choose the combination from a product catalogue. Start from the structure of your chargebacks.
High fraud share, low non-fraud: look first at the risk model and frictionless transactions, then at whether the authentication chain is complete. The gain here comes from sharper risk and a working authentication chain; adding more platforms does nothing.
High non-fraud share: the problem is neither risk nor authentication but fulfilment and support. Either tracking data is not flowing back, or refunds are slow enough that users go straight to their bank. No risk product fixes this.
Both high and concentrated in a few categories or regions: reconsider onboarding policy rather than adding verification steps. Some category-and-region combinations have risk structures that are simply unacceptable and should be declined at onboarding.
Low chargeback count but large disputed amounts: the priority is not fewer disputes but a higher representment success rate and more complete evidence retention - a chargeback-handling capability problem.
For the implementation detail of each layer: the authentication chain is covered in 3-D Secure 2 authentication; risk strategy and signals in payment fraud prevention strategy; reason codes and evidence in chargeback reason codes and evidence; dispute and refund workflows in refund and dispute handling. For where the three sit in the wider stack see the seven layers of a payment stack. More payment options are listed under the payment category.
Source: 16IDC original. The 3DS chain, liability shift conditions and chargeback reason code families follow scheme rules, issuer policy and the relevant provider documentation.