Frictionless Flow vs Challenge Flow: How 3DS Decides Which Your Customer Gets

Every 3DS 2 transaction resolves to one of two paths: frictionless or challenge. This is what's known as risk based authentication: the issuer's Access Control Server (ACS) decides which path a transaction takes, based on the data the merchant submits. The merchant doesn't control the outcome directly. But the merchant controls the data quality, and data quality is what drives the decision.

Frictionless flow: how it works

In frictionless flow, the issuer's ACS performs passive authentication. The exchange happens entirely in the background: the 3DS Server submits the transaction data to the ACS, the ACS evaluates it against the issuer's risk model, and if the risk score is acceptable, authentication is confirmed without any cardholder interaction.

From the customer's perspective, nothing happens. The checkout proceeds normally. From the merchant's perspective, the transaction carries the authentication values (ECI code and CAVV/AAV) that establish the liability shift, even though no challenge was presented.

Industry benchmarks commonly cite frictionless rates in the 80–85% range for merchants sending complete data, with the remainder routed to challenge flow. If you've ever wondered why was I not challenged by 3DS on one purchase but was on another, this is the answer: it's a per-transaction risk score, not a fixed rule.

Challenge flow: what triggers it and what it looks like

The issuer triggers a challenge when its risk model determines the submitted data is insufficient to authenticate with confidence, which is what triggers a 3DS challenge in practice. The challenge is presented inline within the merchant's checkout, embedded via an iframe or native SDK, rather than as a full-page redirect. Common challenge methods include:

• OTP via SMS or email: a one-time passcode sent to the cardholder's registered contact details.
• In-app push notification: the cardholder approves the transaction via their bank's mobile app.
• Biometric authentication: fingerprint or facial recognition via the bank's app, on supported devices.
• Security question: less common in 3DS 2, but still used by some issuers for fallback.

Challenge flow adds friction, and industry research generally puts abandonment among challenged customers in the 10–15% range, varying by country, age group, and familiarity with the bank's authentication method. This isn't a reason to avoid 3DS. It's a reason to fix your data submission.

What the issuer's ACS is evaluating

The issuer's risk decision is a scoring function applied to the data elements submitted in the authentication request. No two issuers use identical models, but the factors that carry the most weight across the industry include:

• ‍Device consistency: Has this device been seen before? Does the device fingerprint match previous successful transactions from this cardholder? A new device that can't be linked to the cardholder's history is a significant risk flag.
• ‍Behavioural signals: Does the transaction fit the cardholder's normal pattern? Unusual transaction time, merchant category, amount, or a short gap since the last transaction can each raise the risk score.‍
• Address match indicators: Does the shipping address match the billing address on record? Is the billing address consistent with the IP geolocation? Mismatches are a strong fraud signal.‍
• Account history: How long has the cardholder had an account with the merchant, and how many successful transactions in the past 90 days? A cardholder with no history at a merchant, placing a high-value first order, is statistically higher risk than a returning customer.‍
• Velocity signals: Has there been an unusual number of transactions on this card in the past hour, day, or week? Velocity checks are a core component of most issuer risk models.

There's no trick here that lets you bypass risk-based authentication. If there were, every merchant would use it and challenge flow would stop existing. What you actually control is whether the ACS has enough signal to make a confident low-risk call. Genuinely risky or ambiguous transactions, a brand-new device, no purchase history, a mismatched shipping address, will still get challenged no matter how clean your integration is, and that's the system working as intended.

How to maximise your frictionless rate

Where merchants lose frictionless rate unnecessarily is incomplete or missing data: fields the 3DS protocol supports but the integration never sends. That's the gap worth closing. Steps that consistently help:

• Implement 3DS Method (browser fingerprinting): Before the authentication request, the 3DS protocol includes a pre-authentication step that collects browser and device data. Many integrations skip this step. Implementing it correctly gives the issuer richer device context to work with, rather than leaving it to score you as an unknown.
• Pass account history fields: Include the cardholder's account age at your platform, number of prior transactions, prior successful 3DS outcomes, and relevant account change history (e.g. a recent password change).
• Include shipping and billing address match indicators: These are explicit data elements in the 3DS 2 protocol. If your checkout collects both addresses, pass the match result to the ACS rather than leaving it to infer.
• Send order context fields: Shipping method, delivery timeframe, digital vs physical goods flag, and reorder flag all feed the issuer's risk picture.
• Avoid sending low-quality or inconsistent data: An email that doesn't match the cardholder's registration, or a shipping address that's clearly a freight forwarder for a domestic merchant, will increase challenge rates rather than reduce them.

None of this eliminates challenge flow, nor should it. It just means the issuer is scoring the transaction you actually have, instead of a thinner, noisier version of it.