Most engineering teams treat the 3DS authentication flow as a coin flip they don’t get to influence: send the request, wait for the issuer’s ACS to return frictionless or challenge, and build the checkout experience around whatever comes back. That assumption isn’t entirely wrong, the issuer does make the final call, but it skips over the part of the flow you actually do control. The data your platform sends in that authentication request has a measurable effect on how often the issuer scores a transaction as low-risk enough to skip the challenge screen. This post breaks down which fields actually move that needle, what’s genuinely out of your hands, and how non-redirect hosted flows keep the authentication step from wrecking your checkout UX.
The 3DS Authentication Flow: What the Issuer Actually Decides
If you’re still asking what is 3DS authentication actually weighing at the point your platform sends the request, the short answer is risk, not identity. Two things happen after that request goes out: the issuer’s Access Control Server (ACS) scores the transaction, and it returns one of two outcomes.
The Two Possible Outcomes
Frictionless authentication means the ACS is confident enough in the transaction’s legitimacy to approve it using only the data submitted in the authentication request and whatever the issuer already knows about the cardholder. Challenge authentication means the ACS wants direct confirmation from the cardholder, typically a push notification, an SMS code, or an in-app approval, before it will authenticate. That decision happens entirely inside the issuer’s risk engine. Successful authentication, either path, shifts fraud liability from you to the card issuer, which is the entire reason 3DS exists as a category.
What the Issuer’s ACS Is Actually Scoring
The ACS pulls from data the issuer already has about the cardholder: transaction history, typical spend patterns, device reputation, and geolocation consistency. It combines that with whatever your platform submits in the authentication request. A first-time purchase from a new device in an unfamiliar country reads very differently than a repeat purchase from a recognized device on a known network. None of that scoring model is visible to you, and none of it is something you can adjust after the fact. What you can adjust is the completeness and quality of the data your platform hands the ACS before it makes that call.
The Data Signals That Shape Frictionless Approval
This is where engineering choices actually matter. The 3DS authentication flow accepts a defined set of data elements in the authentication request, and issuers weight them differently, but sparse or missing fields consistently correlate with lower frictionless authentication rates across PSPs.
Device and Session Fingerprint Data
Browser info, screen resolution, time zone, and installed plugin data all feed the device fingerprint the ACS checks against what it’s seen from that cardholder before. A device the issuer recognizes from prior purchases scores very differently than a device with a thin or missing fingerprint. Teams that strip this data out to simplify their checkout payload, intentionally or by accident during a redesign, tend to see their frictionless rate drop without an obvious cause. Fields like this are the first thing worth auditing when frictionless rates fall for no clear reason.
Transaction and Cardholder Context
Order amount, currency, shipping address match, billing address match, and account age all factor into the risk score alongside device data. Orchestra’s card-not-present research shows 3DS2 risk models weigh over 100 data points, spanning device fingerprint, transaction history, and shipping address consistency, to decide whether a challenge is necessary. Every one of those fields your platform can control originates somewhere in your checkout flow, which means gaps in your integration show up as gaps in the issuer’s risk picture, not as random challenge outcomes.
Preserving Authentication Data Across a PSP Boundary
If your platform routes across more than one PSP, the ECI, CAVV, and transaction ID values generated during authentication have to survive the handoff to authorization intact, or the liability shift breaks even when the authentication itself succeeded. Maintaining that data integrity across a PSP boundary is one of the more overlooked engineering requirements in a multi-provider 3DS authentication flow. It’s a detail that rarely surfaces until a chargeback dispute reveals the liability shift didn’t actually hold.
Orchestra’s payments compliance outsourcing keeps that data integrity consistent across every processor you route through, so authentication results hold up the way they’re supposed to.
Where Non-Redirect Hosted Flows Fit In
None of the data signal work matters if the authentication step itself breaks the checkout experience. This is the part of the flow that determines whether you can get the security benefit of 3DS without sending customers off-page.
What Non-Redirect Actually Means
A redirect flow sends the cardholder to a separate authentication page, often on the issuer’s domain, before returning them to checkout. A non-redirect hosted flow keeps the cardholder inside your checkout UI by rendering the ACS challenge, when one occurs, in an embedded iframe or modal rather than a full-page redirect. Frictionless outcomes don’t show the cardholder anything either way, so the distinction only matters when a challenge is triggered. For the share of transactions that do get challenged, hosted flows are the difference between a jarring context switch and a checkout experience that barely changes.
It Doesn’t Change What the Issuer Scores
Switching from redirect to non-redirect doesn’t alter the authentication data your platform sends, and it doesn’t change the ACS’s frictionless or challenge decision. It changes only how the challenge, if one happens, gets presented to the cardholder. Teams sometimes assume a hosted flow will reduce challenge rates on its own; it won’t, because the risk scoring happens before the UI decision is even made. What it does reliably improve is completion rate on the transactions that do get challenged, since customers are far more likely to abandon at a full-page redirect than an embedded prompt.
What Engineers Can’t Control (and Shouldn’t Try To Work Around)
Some of what determines frictionless vs. challenge really is outside your reach, and it’s worth being direct about which parts those are so you’re not chasing a fix that doesn’t exist.
The Issuer’s Final Risk Threshold
Each issuer sets its own risk tolerance, and that tolerance shifts based on fraud trends the issuer is seeing that have nothing to do with your platform. A card network reporting a wave of fraud on a particular BIN range can tighten thresholds overnight, and your frictionless rate for cardholders on that BIN drops without any change on your end. Retry logic and routing decisions can work around a slow or unresponsive ACS connection, but they can’t override a legitimate risk decision the issuer has already made.
Regional and Regulatory Overrides
In markets with mandatory strong customer authentication, regulation can force a challenge regardless of how clean your data signals are. Exemption eligibility, where it exists, still runs through the issuer’s discretion, not a guarantee your platform can request and receive. Building your checkout UX around the assumption that clean data always earns frictionless treatment sets up a mismatch between engineering expectations and issuer reality.
Diagnosing a 3DS Implementation That’s Quietly Hurting Conversion
Most teams don’t discover their 3DS authentication flow is degrading conversion until someone pulls the numbers months later. A few checks catch it earlier.
Signs Your Frictionless Rate Is Lower Than It Should Be
If your frictionless rate sits meaningfully below the 85 to 95 percent range issuers typically achieve for 3DS2 transactions, that’s a signal worth investigating before assuming it’s just issuer behavior. Compare frictionless rates across PSPs if you route through more than one; a gap between providers usually points to a data field one integration is dropping. A sudden rate drop after a checkout redesign is almost always a fingerprinting or field-mapping regression, not a change in issuer behavior.
What to Audit First
Start with the device fingerprint and browser data fields, since those are the ones most often stripped out during redesigns or privacy-focused checkout changes. Confirm ECI, CAVV, and transaction ID values are surviving intact if your traffic crosses a PSP boundary at any point. The same health monitoring discipline that keeps a payments gateway resilient during a provider outage applies here: know your baseline authentication data completeness before something breaks it.
Build the 3DS Authentication Flow Around What You Actually Control
The frictionless vs. challenge outcome was never as binary as it’s often treated. The issuer makes the final call, but the data quality, field completeness, and cross-PSP consistency feeding into that call are entirely within engineering’s reach, and they’re usually where the real conversion losses are hiding.
Orchestra handles the 3DS authentication flow at the orchestration layer, preserving ECI, CAVV, and transaction ID data across every processor a transaction touches and keeping compliance scope consistent regardless of which PSP ultimately authenticates the card. If your team is trying to figure out whether a conversion drop is coming from issuer behavior or from something in your own data pipeline, that’s a conversation worth having before the next redesign, not after.
