Start by measuring 3DS as a sequence, not one approval number: attempted auth, challenged, challenge completed, authentication result, authorized, and abandoned. Then separate PSD2/Strong Customer Authentication in-scope traffic from non-mandated cohorts before changing policy. Use merchant/acquirer, issuer, and interoperability records plus retry/idempotency markers to classify failures. That tells you whether drop-off came from request quality, challenge handoff, or issuer-side behavior.
3D Secure is easier to manage when you stop treating it like a single fraud setting. In card-not-present payments, it works more like a shared conversion funnel across three parties: the acquirer domain, the issuer domain, and the interoperability domain that connects them. That matters because checkout loss can start with your request, with an issuer challenge decision, or with how those domains pass state back and forth.
If your team only watches approval rate, you will miss where customers actually drop out. Drop-off can happen at multiple points across authentication and authorization, and those are different problems with different owners. The first useful move is to split the path into at least these checkpoints: authentication attempted, challenge presented, challenge completed, authentication result, and final authorization result.
That separation matters even more under PSD2 and Strong Customer Authentication. In European SCA contexts, 3DS is often part of the compliance path for CNP transactions, but a poor result is not automatically a compliance problem or a merchant policy problem. The issuer can require more authentication, and issuer support also affects which 3DS version flow runs in the first place. So if you see a sudden drop in completion, do not assume your checkout copy or risk settings caused it. First confirm whether the change is concentrated in a specific issuer or card range.
A useful operating habit is to make sure every failed or abandoned authentication can be tied back to a concrete cross-domain record trail in your PSP or acquirer reporting. You want fast answers to basic questions: was the auth request sent, was a challenge actually triggered, did the issuer return a result, and did the payment then reach authorization? Without that linkage, teams waste days arguing about whether a conversion issue is product UX, issuer behavior, or a reconciliation gap.
This article is for platform teams that need a decision path, not a generic 3DS explainer. The focus is what to measure, how to segment, and when to change policy without losing sight of PSD2 and SCA constraints. One recommendation up front: do not ship a single global policy from blended results. Issuer and scheme behavior can vary by market and program, so validate every recommendation against your own cohort data before you call a conversion problem solved. For a step-by-step walkthrough, see When Freelancers Need a Data Processing Agreement and What to Redline First.
Start with definitions before you tune anything: 3DS is the protocol that requests issuer authentication before authorization, and 3DS2 is the newer version of 3DS1. For conversion, use one standard in this section: a payment converts only when authentication is followed by successful authorization.
Control is split across domains, so map ownership before changing rules or UX. Your side controls the 3DS request and checkout experience around it. The issuer domain often controls whether a challenge is required and whether that challenge is completed successfully.
Treat Visa Secure and Mastercard Identity Check as network-branded implementations of the same core 3DS protocol. If someone reports "Visa Secure issues" or "Identity Check drop-off," clarify whether the problem is issuer behavior or your implementation path before acting.
Use this as an operating gate: if your team cannot name the owner for each failure state, pause optimization. At minimum, confirm you can trace whether the 3DS request was sent, whether the issuer returned an authentication result, and whether the payment then reached authorization. If you want a deeper dive, read Beneficial Ownership Collection for Marketplace Onboarding: How to Capture UBO Data Without Killing Conversion.
3D Secure 2 is not a rebrand of 3D Secure 1: it changes data depth and device coverage, and that can improve frictionless outcomes, but conversion still depends on implementation quality.
| Conversion-critical behavior | 3D Secure 1 | 3D Secure 2 |
|---|---|---|
| Redirect behavior | Legacy flow was limited to browser-based transactions, and redirect-heavy handoffs can add drop-off risk | Supports newer checkout patterns and is not limited by old browser-only constraints |
| Mobile and in-app UX | Browser-dependent legacy experience | Designed for modern device coverage, including mobile and in-app payments |
| Data exchange depth | Lower issuer input | EMV 3DS can exchange 10x more data than 3DS 1.0 (per Mastercard) |
| Frictionless eligibility | Less room for passive risk-based issuer decisions | Supports risk-based, frictionless authentication where cardholders can be passively authenticated |
| Scheme | Legacy/previous label you may still see | Current or active program label |
| --- | --- | --- |
| Visa | Verified by Visa | Visa Secure |
| Mastercard | SecureCode | Mastercard Identity Check |
| American Express | SafeKey | SafeKey |
| Discover | ProtectBuy | ProtectBuy |
| JCB | J/Secure | J/Secure |
Richer issuer input can help reduce unnecessary challenges, but it does not rescue weak execution. Redirect breaks, poor return-path handling, or thin event logging can still suppress conversion even on 3DS2. Adyen explicitly notes that redirection can lower conversion when shoppers abandon or redirects fail.
For most teams, the practical move is to update decisioning and instrumentation assumptions first, then tune UX. If you cannot reliably trace a payment from authentication request to issuer outcome to final authorization, you risk optimizing screens while the real losses sit in handoffs or issuer decisions. Related: How to Secure Your Devices for International Travel.
Before you change any risk rule, lock the measurement model. For CNP transactions, use one canonical funnel with fixed event names, and keep authentication separate from authorization.
Use the same six stages everywhere: attempted auth, challenged, challenge completed, authentication result, authorized, and abandoned. If product analytics, PSP exports, internal logs, and reconciliation files rename these steps differently, you lose comparability and end up debating labels instead of diagnosing losses.
| Event name | What it should mean | Recommended checkpoint owner | Minimum evidence to store |
|---|---|---|---|
| attempted auth | A payment attempt entered 3DS processing | Engineering confirms event integrity; product confirms trigger point | Provider reference when available, timestamp, retry/idempotency marker, scheme/provider response field if returned |
| challenged | The issuer requested a challenge | Product monitors handoff UX; payments ops monitors issuer pattern shifts | Provider reference or ACS reference when available, timestamp, scheme/provider response, retry marker |
| challenge completed | The customer finished the challenge step | Product checks drop-off; engineering checks callback/state return | Provider reference, timestamp, scheme/provider response, retry marker |
| authentication result | Final authentication outcome was returned | Payments ops validates success/failure coding | Provider reference, scheme/provider response, timestamp, retry marker |
| authorized | The payment reached authorization and got a final response | Finance and payments ops reconcile auth to payment outcome | Provider reference, acquirer/authorization response, timestamp, retry marker |
| abandoned | The flow ended before a completed payment outcome | Product tracks session loss; finance checks unmatched attempts | Timestamp, retry marker, explicit null provider reference if none exists yet, last known response state |
Treat the ownership column as an operating recommendation, not a universal standard. The practical goal is shared accountability: product for handoff and exits, engineering for event integrity and duplicate protection, payments ops for issuer/provider interpretation, and finance for ledger-level reconciliation.
Do not collapse "authentication succeeded" into "payment converted." Authentication and authorization are separate stages, so a payment can authenticate successfully and still fail later at authorization.
Use both conversion and authentication datasets, because they answer different questions. Keep both raw and deduplicated views too: raw captures repeat attempts; deduplicated collapses retries tied to the same payment.
For triage, use this as a starting rule: if abandonment rises while challenge completion is stable, inspect pre-auth UX and request formation before tightening risk policy. That pattern is directional, not proof, but stable challenge completion makes issuer challenge flow a weaker first suspect, especially since merchants have limited control over external challenge pages.
Two controls prevent false conclusions: trace each payment from authentication to authorization with a stable provider reference, and persist retry/idempotency markers on every event. If the same idempotency key returns the same result (including 500 errors), replays can distort drop-off rates unless you deduplicate correctly. Also retain evidence quickly; if you rely on Stripe Events, retrieval is limited to 30 days. You might also find this useful: What is Two-Factor Authentication (2FA) and Why You Need It.
Do not tune 3DS policy from one blended success rate; segment first, starting with mandate context. A global average can hide losses in one cohort and overstate gains in another, so split European Union PSD2/SCA in-scope remote payments from non-mandated regions before you compare outcomes.
| Cut or view | What to split | Why it matters |
|---|---|---|
| Mandate context | PSD2/SCA in-scope remote payments vs non-mandated regions | Start here before comparing outcomes |
| Device class | Desktop and mobile | Operationally important for challenge UX |
| Payer state | Where available | Part of customer-context segmentation |
| Challenge status | Challenge vs frictionless outcome | Challenge rate is a defined funnel metric |
| Scheme brand | Visa Secure, Mastercard Identity Check, American Express SafeKey | Scheme-level cuts can expose diagnostic differences |
| Raw view | Repeat attempts | Shows operational load and retry behavior |
| Deduplicated view | Final outcome per payment | Collapses retries tied to the same payment |
This is the hard boundary because the operating context differs. PSD2 Article 97 in Directive (EU) 2015/2366 establishes strong customer authentication for electronic remote payment transactions, which is enough to separate in-scope remote payments from non-mandated cohorts even without modeling every trigger or exemption.
Use explicit saved filters in your dashboard instead of blended totals or ad hoc views. If a payment attempt does not carry a stored mandate-context flag in your analytics layer or export, treat that segment as unfit for policy decisions.
Inside each mandate cohort, segment by device class, payer state where available, and challenge versus frictionless outcome. Device class is operationally important for challenge UX across desktop and mobile, challenge rate is a defined funnel metric, and frictionless outcomes depend in part on issuer-side ACS risk-based rules.
Keep two views side by side:
Raw data includes repeat attempts, while deduplicated data reflects the final outcome for attempts tied to the same payment. If first-time versus returning payer is not reliably available in your PSP data, do not infer it.
Where available, split results by Visa Secure, Mastercard Identity Check, and American Express SafeKey. These are branded EMV 3-D Secure programs, and scheme-level cuts can expose meaningful diagnostic differences that disappear in blended reporting.
Use a consistent evidence pack per segment: mandate flag, scheme brand, device class, challenge status, provider reference, and retry marker. Keep the policy rule simple: do not ship one global 3DS policy from blended data; tune by segment with explicit guardrails so you do not label a shift in where losses appear as a true win. Related reading: The Best Cloud Storage Providers with European Data Centers.
Treat drop-off diagnosis as a failure-mode exercise, not a debate. Classify each lost payment into a small set of failure modes, then require evidence from all three EMV 3DS domains before changing policy. This keeps you from blaming checkout UX for an issuer decision, or blaming issuers for a retry bug in your own stack.
EMV 3DS is a three-domain model: merchant/acquirer, issuer, and interoperability. Your checklist should mirror that. For each suspect payment, capture the merchant-side request payload, the interoperability reference (such as the directory server transaction ID when exposed), and the issuer outcome, including authentication result and failure reason code.
Keep the checklist short and operational:
| Failure mode | What it usually means | Required artifacts | First thing to verify |
|---|---|---|---|
| Challenge not presented | You expected a challenge, but the flow stayed frictionless or stopped earlier | Request payload, provider reference, interoperability reference, issuer result | Whether the issuer actually escalated for further checks; issuer frictionless rules are optional and can change |
| Challenge abandoned | Shopper reached challenge flow but did not complete it | Redirect/challenge event trail, timestamps, provider reference, issuer result | Whether loss happened during redirect or challenge handoff |
| Auth failed | Authentication completed with a failure result | Full request payload, issuer failure reason code, scheme context | Whether the code is generic or scheme-specific, and whether the payload was malformed or incomplete |
| Auth passed but not authorized | 3DS succeeded, but card authorization still failed | Authentication result, DS transaction ID, authorization request and response | Whether the authorization request carried required 3DS data forward |
| Duplicate attempt confusion | Multiple attempts make one payment look like several losses | Idempotency key, retry marker, related events, timestamps | Whether retries reused the same key and whether reporting deduplicated correctly |
Duplicate attempts are easy to underestimate. Refreshes, network retries, and app re-submits can create extra auth attempts for one payment and make a stable funnel look broken.
Do not stop at "the PSP says it failed." In EMV 3DS 2.1 and later, issuer authentication services can return numeric failure indicators, and codes can be generic or scheme-specific. If your export only says failed, you are missing the field that often separates request-quality issues from issuer-side decisions.
For the auth-passed-but-not-authorized bucket, continuity is the checkpoint. Some authorization requests need protocol references from the authentication step, and Mastercard requires the 3-D Secure version plus directory server transaction ID in authorization. If those values are dropped between steps, you can see clean authentication followed by an avoidable authorization decline.
Also expect scope mismatch between authentication and final payment reporting. Authentication datasets can include drop-offs and may exclude some exempt or non-attempted 3DS transactions, so a one-to-one count match is not a reliable standard.
Use mechanical checks. For retries, confirm idempotency: repeated requests with the same key should return the same stored result, including errors. Without log proof, duplicate-attempt analysis is not trustworthy.
For webhooks and async events, handle duplicates and check chronology by timestamp. Arrival order is not a safe ordering signal, especially when retries can continue for extended periods (in some cases up to 30 days). If state transitions depend on arrival order instead of timestamp plus deduplication, you will create false abandonments and false recoveries.
Make the policy tradeoff explicit: forcing more challenges can reduce fraud exposure in some cohorts, but it can also raise abandonment, especially on redirect-style paths. If a low-risk, non-mandated cohort is already authorizing well, do not force challenge by default. Use checklist evidence first, then tighten policy only when results show a real issuer or risk need rather than a logging gap.
We covered related operational reporting patterns in How to Automate Client Reporting with Google Data Studio and Supermetrics. If you want an immediate operational next step, try the free invoice generator.
Roll out 3DS changes in a fixed sequence and isolate one major change per release cycle so you can attribute results to the right cause. Use the same evidence pack before and after each change.
| Step | Action | Check |
|---|---|---|
| 1 | Lock the metric taxonomy first | Freeze event names and required fields before editing policy or UX |
| 2 | Run instrumentation QA | Test 3DS and dispute scenarios in sandbox, then validate with real payments after live configuration |
| 3 | Read a baseline cohort | Capture a clean pre-change view for the cohorts that matter, including SCA in-scope traffic |
| 4 | Change policy before UX | Tune when to request 3DS first; the issuer decides whether a challenge is required |
| 5 | Change UX after policy effects are visible | Keeps issuer behavior and UX impact from getting mixed together |
| 6 | Run a post-change audit | Reconcile conversion, risk outcomes, and finance reporting at transaction level |
Set owners before launch, even if one person covers multiple areas. A practical split is engineering for event integrity and live-payment validation, product for challenge and redirect UX decisions, and finance ops for reconciliation, exceptions, and chargeback monitoring.
Use a short go/no-go check: confirm 3DS support for SCA in-scope transactions, define expected conversion impact by cohort, and verify risk and chargeback monitoring is active. As part of readiness, review and customize your risk profile, then test real payments in live.
After launch, check transaction-level reconciliation using the settlement details report (or your provider equivalent), not only topline conversion or approval movement. That is where handoff and exception issues become visible.
Also account for activation timing in your first read. Mastercard 3DS enrollment can take up to 12 hours, so immediate movement may reflect rollout timing rather than user response. If you need a deeper implementation view, see 3D Secure 2.0 for Platforms: How to Implement SCA Without Killing Checkout Conversion.
Need the full breakdown? Read How to Secure a REST API: Prevention, BOLA Protection, Detection, and Response.
PSD2/SCA scope must be confirmed per market and program, not assumed globally. For online card payments, SCA is generally relevant for customer-initiated transactions where both the business and the cardholder's bank are in the EEA, and UK/Europe framing also centers on customer-initiated payments. Out-of-scope cases and exemptions still apply.
Coverage varies by country, acquirer/PSP setup, and issuer program configuration. Local directives can place obligations on you, the issuing bank, or both, and issuer frictionless rules can change over time. In the UK, the FCA states the rules have applied since 14 September 2019, with the same "unless an exemption applies" caveat.
| Confirmation area | What to verify | Evidence or scope |
|---|---|---|
| Legal/compliance | Whether the flow is customer-initiated and which jurisdictional scope applies | Which exemptions may apply under that regime |
| Acquirer/PSP | Your entity, market, and configuration | What applies when enabled, where supported, and what varies by program |
| Issuer-side test evidence | Approved live or test flows | Evidence of the authentication and issuer outcome |
Keep this month focused on three outputs: one shared 3DS scorecard, two core reference tables, and one controlled cohort test. If PSD2/SCA coverage is unclear for a target market or program, pause policy expansion until that scope is confirmed.
| Deliverable | Must include | Checkpoint |
|---|---|---|
| Shared 3DS scorecard | Customer-initiated transaction filter, authorization rate, 3DS conversion rate, funnel stages from attempted auth to authorized/abandoned, failed BIN concentration, country/currency cuts | Product, engineering, payments ops, and finance sign off on the same definitions and owners |
| 3D Secure 1 vs 3D Secure 2 table | Redirect behavior, mobile UX, data depth, frictionless assumptions, and a note that some integrations run 3DS2 when supported and fall back to 3DS1 otherwise | Engineering confirms what your PSP/payment stack does in production |
| Event-level metric schema | Attempted, challenged, challenge completed, authentication result, authorized, abandoned, plus provider reference, scheme response, timestamp, and retry/idempotency marker | Finance and engineering can reconcile authentication reporting vs conversion reporting |
Start with the scorecard and keep authentication reporting separate from conversion reporting, since they answer different questions. Assign one owner per metric so decisions come from one shared funnel view.
Run one test that changes one variable in one cohort. Define cohorts from customer-initiated traffic plus a clear segment (for example country, currency, or BIN groups with the largest failed 3DS volume). If you want to relax 3DS for a targeted cohort, check that cohort's authorization performance first, and treat fraud safeguards as part of the same decision.
Use a strict go/no-go rule after the test. Keep the change only when conversion, authorization success, and compliance evidence all align. If evidence cannot show which authentication path fired per attempt, treat results as inconclusive and fix instrumentation first.
Mandates and issuer behavior can shift during rollout. 3DS may be triggered by regulation or issuer soft-decline conditions, and issuer frictionless rules can change over time. Confirm market/program constraints with your provider and compliance owner before scaling.
This pairs well with our guide on How to Calculate the Cash Conversion Cycle for a Service Business. Want to confirm what's supported for your specific country/program? Talk to Gruv.
In plain terms, 3DS is the data exchange between your checkout side and the issuer before a card payment is authorized. The conversion part is not just whether authentication happened. It is the full path from offer or attempt through authentication result, authorization, and any customer drop-off.
No. Both 3D Secure 1 and 3D Secure 2 can be used to apply SCA under PSD2, and better results are not automatic just because you upgraded the protocol version. The practical pattern is simpler: implementation quality in the authentication flow is what drives business impact.
Drop-off can happen at multiple points in the path, including during authentication and before final authorization. A useful checkpoint is to review the authentication outcome together with the final authorization result for the same attempt instead of reading one screen in isolation.
Track a consistent funnel every week: authentication attempted, challenged, authentication result, authorized, and abandoned. Keep one evidence layer with the threed_authentication_response field so you can explain why an authorization attempt ended the way it did. Also keep authentication reporting and conversion reporting separate, because their scopes are not the same and the conversion view can include customer drop-off.
It is generally in scope when both your acquiring processing entity and the customer’s issuer processing entity are in the EEA, and scope checks can also include Monaco or the UK depending on setup. It is not a worldwide rule for every card payment. If the payment is in scope, issuers can refuse non-compliant transactions.
Start with mandate context first: PSD2/SCA in-scope traffic versus non-mandated traffic. Then segment by market and by challenge versus frictionless outcomes. That matters because issuer and cardholder behavior differs by market, so a blended regional average can hide a bad country policy.
You can control your request quality, your checkout UX, and whether your instrumentation lets you see where users drop out. You cannot directly control issuer challenge decisions or final issuer approval behavior, so treat those as monitored dependencies rather than knobs you own. If you need to prove a problem is issuer-side, keep the authentication outcome and final authorization outcome together for the same attempt.
Avery writes for operators who care about clean books: reconciliation habits, payout workflows, and the systems that prevent month-end chaos when money crosses borders.
Includes 1 external source outside the trusted-domain allowlist.
Educational content only. Not legal, tax, or financial advice.
Treat 3D Secure 2 as an architecture choice, not a compliance box to tick. For a platform, the way you introduce 3DS2 changes how you meet Strong Customer Authentication requirements in Europe. It also changes how often customers get interrupted and how much payment logic you tie to a single checkout surface.
For **beneficial ownership collection in marketplace onboarding**, the real question is not whether you need one more form. It is whether you can explain who owns or controls the business before you activate it, enable payouts, or defend the decision later. If you treat ownership data as only a filing issue, you will either slow down good users with unnecessary asks or approve risky ones without a clean evidence trail.
If your income runs through your phone and laptop, device security is continuity planning, not a gear-shopping task. The goal is simple: keep delivery, billing, and recovery moving when travel conditions change faster than expected.