3-D Secure and risk-based authentication: deciding which payments to challenge

Risk-based authentication means you do not challenge every card payment. You score each payment first, let low-risk ones through without friction or with an exemption where the rules allow, send medium-risk ones through a 3-D Secure challenge, and block the clearly fraudulent. It keeps authentication where it adds protection and removes it where it only adds friction.

Updated 1 November 2026 · RiskCogs team

When a customer pays online, 3-D Secure lets the cardholder's bank check that the person paying is the real cardholder. Version 2 of the protocol sends the issuer a rich set of data about the payment and the device: amount, merchant, browser details, shipping address, account age and more. The issuer uses that data to decide what to do.

There are two outcomes the customer may experience. In the frictionless flow, the issuer is satisfied by the data alone and approves authentication without asking the customer for anything. In the challenge flow, the issuer asks the customer to prove who they are, usually by confirming in a banking app or entering a one-time code.

The merchant does not decide which flow happens. The issuer does. What the merchant decides is whether to request authentication at all, whether to ask for an exemption, and how much data to send to help the issuer decide.

Challenges cost conversions. Some customers do not have their phone at hand, some banking apps are slow, and some challenge pages break on mobile browsers. Each of these turns a willing buyer into an abandoned checkout. For returning customers buying small amounts, the added protection is minimal and the friction is real.

Challenges also do not stop all fraud. Fraudsters who control a victim's phone or email, or who trick the victim into approving a payment, can pass authentication. So authentication works best as one layer in a risk strategy, not as the whole strategy.

1. Score the payment before you request authentication, using device, network, card and history signals.
2. Low score: request authentication with an exemption where you qualify, or rely on the frictionless flow by sending full data.
3. Medium score: request authentication and ask for a challenge, so the issuer verifies the customer.
4. High score: block the payment before it reaches the issuer.
5. Record the authentication result next to the score, and feed outcomes back so the bands improve.

In the EEA, the regulatory technical standards on strong customer authentication list situations where a payment does not need to be strongly authenticated. Two matter most for card-not-present merchants.

Low-value payments under Article 16: remote payments up to €30 can be exempt, subject to cumulative limits on amount and number of consecutive transactions, after which authentication is needed again.

Transaction risk analysis under Article 18: a payment provider can skip authentication for payments it assesses as low risk, provided its fraud rate stays below reference levels set for each amount band. The regulation sets reference fraud rates of 0.13% for remote card payments up to €100, 0.06% up to €250 and 0.01% up to €500.

The exemption is requested by the acquirer or issuer, not by the merchant directly, and the issuer can always refuse and demand a challenge. Merchant-initiated transactions, such as recurring billing after the first authenticated payment, are out of scope of SCA when flagged correctly. Check with your payment provider which exemptions they support and how to request them.

When a payment is successfully authenticated, liability for many fraud-related chargebacks moves from the merchant to the issuer under card network rules. That is a strong reason to authenticate risky payments rather than block them outright.

The shift has limits. It applies to fraud-coded disputes, not to item-not-received or not-as-described claims. It may not apply when an exemption was used, since the payment was not authenticated. And the exact rules vary by card network and region. Treat liability shift as useful protection for the medium-risk band, not as a reason to authenticate everything.

• Pass the full set of 3-D Secure 2 fields your payment provider supports, including billing and shipping address, email and phone.
• Include account information such as account age and earlier purchases.
• Keep the device data collection step on your checkout page fast and reliable.
• Use the same descriptor and merchant details consistently, so issuers recognise you.
• Watch challenge and success rates by issuer and country to find integration problems.

Here is how routing might look for three payments in an online store. The scores are made-up examples to show the logic, not real results.

Example one: a returning customer, same phone as their last three orders, home IP, €40 basket. Example score 12. The payment is sent with full data and a request for an exemption or the frictionless flow. The customer sees no extra step.

Example two: a new account, card issued in one country, IP in another, €180 basket, email created this week. Example score 55. Nothing here proves fraud, but there is enough doubt to ask the issuer to verify the cardholder. A challenge is requested. If the customer passes, the order ships, and fraud-coded disputes on it are generally the issuer's liability.

Example three: a data-center IP, a device seen with eight different cards in the past hour, and a burst of small failed attempts. Example score 88. This is card testing. The payment is blocked before it reaches the issuer, which also protects your authorisation rates.

• Challenging every payment because it feels safer, then wondering why mobile conversion fell.
• Asking for exemptions on payments your own score marks as risky, which gives up liability shift exactly where you need it.
• Treating a successful challenge as proof that the order is safe, and skipping checks on address changes or reshipping.
• Sending minimal data in the authentication request, which pushes issuers toward challenges.
• Never revisiting thresholds after launch, even as traffic and fraud patterns change.

Track four numbers together: the share of payments sent to authentication, the challenge rate among those, authentication success rate, and fraud and chargeback rates in each risk band. If challenge rates are high and success rates are low for one issuer, look at the data you are sending. If fraud appears in the low band, your score thresholds need adjusting.

Make changes one at a time and give each change enough time to show outcomes. Chargebacks lag payments by weeks, so a threshold moved on Monday cannot be judged by Friday.

RiskCogs scores each payment through POST /v1/risk-score before you request authentication. The default bands map neatly to routing: allow under 40, review or 3-D Secure from 40 to 69, block from 70. Reason codes such as bin_country_mismatch_ip or ip_datacenter explain why a payment landed in a band.

RiskCogs does not run 3-D Secure itself; your payment provider does. RiskCogs tells you which payments are worth challenging. Start in shadow mode on the free plan to see how your current traffic would be routed.

• Commission Delegated Regulation (EU) 2018/389 (RTS on strong customer authentication), Articles 16 and 18 and Annex, as published in the Official Journal of the EU, 13 March 2018.
• EMVCo, EMV 3-D Secure Protocol and Core Functions Specification, version 2.
• Visa, Visa Core Rules and Visa Product and Service Rules (public edition).

• Transaction risk scoring
• False declines
• Payment fraud prevention
• Fraud detection API docs
• Pricing
• Talk to the RiskCogs team