3D Secure Conversion Data for Authentication Drop-Off Decisions

Measure authentication and payment separately#

A customer can authenticate successfully and still receive a card decline. Another can complete authentication without seeing a challenge at all. If your dashboard treats “challenged” as a required step for every payment, it will report healthy frictionless traffic as missing or lost.

EMVCo describes EMV 3DS as an exchange of transaction, payment and device information between the merchant and issuer to authenticate the customer. It helps prevent card-not-present fraud. Your conversion analysis must then connect that authentication record to the payment that follows.

Keep three questions separate: did authentication succeed, did the issuer authorize the payment, and did the business capture the intended amount? Authorization can be a useful checkout metric, but it is not proof of capture or settlement. Define which outcome your report calls conversion.

Build a branching funnel#

Adyen’s 3DS guide distinguishes a frictionless flow, with no further shopper interaction, from a challenge flow requiring interaction. The issuer determines the authentication path using the information and applicable rules. A challenge that was never requested is not customer abandonment.

Use the provider’s documented response meanings. “Attempted authentication” is not necessarily authenticated success. Preserve raw codes and map them to explicit business categories. Also separate exempt or out-of-scope payments that did not enter this 3DS funnel from traffic that did.

Worked example: 1,000 attempts#

These numbers illustrate the calculation; they are not industry benchmarks. Suppose 1,000 distinct attempts enter 3DS. Of 700 frictionless attempts, 680 authenticate successfully and 20 fail. The other 300 require a challenge, and all 300 are presented in this example. Of those, 240 authenticate successfully, 20 complete the challenge but fail authentication, and 40 are confirmed abandoned.

Now suppose 900 of the 920 authenticated attempts reach authorization, 860 are approved and 40 are declined. The 20 missing authorization submissions need investigation. Authorization approval among submitted requests is 860 ÷ 900, or 95.6%; approved payments per original 3DS attempt are 860 ÷ 1,000, or 86%. Those rates answer different questions.

If 850 of the 860 approved payments have their full intended amount captured by the observation cutoff, full-capture completion per original attempt is 85%. The remaining 10 need their own status. Neither a successful challenge nor a final authorization response should be labelled a completed paid transaction without the relevant payment evidence.

Keep payment identity and observation windows clear#

Store a stable checkout or payment ID and a separate attempt ID. Link the provider payment reference, authentication reference, exposed directory-server reference, authorization and capture records. Multiple webhook deliveries for one attempt are duplicates; a customer’s genuine new attempt is a separate attempt that may belong to the same checkout.

Maintain an attempt-level view for troubleshooting and a checkout-level view for customer conversion. State whether the latter uses first attempts, the latest resolved attempt, or successful payment within a defined window. Do not silently collapse all retries and call the result an attempt rate.

Use the same observation cutoff for compared cohorts. Keep pending and unknown results visible; classify abandonment only after an appropriate inactivity window and checks for later provider outcomes. A customer closing a browser does not prove that a server-side payment failed.

Adyen’s authentication report has its own inclusion rules and outcome fields, including authentication and exemption information. Join it to payment reporting using supported references instead of demanding identical totals from differently scoped datasets.

Diagnose the loss before changing policy#

Collect the evidence your integration exposes; do not make access to every internal issuer or directory-server record a prerequisite to action. Request additional provider investigation when the available records cannot explain the failure. Avoid storing unnecessary sensitive card or authentication data in general analytics logs.

A frictionless result is not a failure merely because the merchant expected a challenge. Likewise, rising abandonment with stable challenge completion does not by itself identify a pre-authentication problem: changing branch proportions and denominators can produce that pattern. Inspect counts, comparable cohorts and the actual stage of loss.

Handle asynchronous results without false losses#

Authenticate and durably store incoming events before acknowledgment. Track receipt separately from processing, and commit the local state change, any accounting effect and outbound work recoverably before marking the event processed. Repeated deliveries must not create another attempt or another capture.

Arrival order and timestamps alone do not establish valid state. Use the provider’s current object, documented version information where available, and allowed transitions. A late result can resolve uncertainty; a later refund or dispute can be a legitimate adverse event rather than stale data.

Persist the original operation identity before authorization or capture dispatch. If the response is lost, retrieve or safely replay that same operation under the provider’s guarantees before creating a new charge or capture. A timeout should create an unknown state, not an automatic duplicate payment.

Use Stripe’s authentication-flow documentation or your provider’s equivalent to implement its actual lifecycle. Report provider-specific statuses as such rather than present one field name as a universal 3DS standard.

Segment by the applicable SCA context#

EEA PSD2/SCA rules and the UK’s SCA framework are distinct legal contexts. Identify the acquiring and issuing processing entities, transaction type, applicable regime and any valid exemption or out-of-scope treatment with the provider and compliance owner. Customer location alone is not a sufficient global scope rule.

The FCA explains the UK SCA framework. Do not describe the UK as an EEA member or automatically treat Monaco and Switzerland as EEA jurisdictions. A provider can route businesses in those markets through an EEA processing entity or apply a wider configuration.

For example, Adyen’s compliance guide describes its processing scope across the EEA, Monaco, Switzerland and UK. That is relevant to an Adyen integration, but should not be copied as the legal geography of PSD2 for every provider.

Inside each applicable context, compare issuer or card-range groups, scheme, device, SDK or redirect flow, amount band, and the authentication path. Keep enough observations to avoid overinterpreting tiny samples. A shift toward issuers that challenge more often can change the blended rate without any checkout regression.

Use current EMV 3DS rather than a legacy fallback plan#

3DS1 belongs in historical comparisons and old data interpretation. Visa’s sunset notice documents discontinuation of 3DS 1.0.2 support. Do not plan a new integration around automatic fallback to that legacy protocol.

Confirm the EMV 3DS versions and flow types supported by your current PSP, SDK and issuer routes. Browser and app behavior can differ, so test the relevant handoffs. A version upgrade does not automatically raise conversion; correct request data and reliable continuation still matter.

Change one cause at a time#

Start with a defined baseline and reliable instrumentation. Fix a confirmed broken redirect or missing continuation directly; there is no universal rule that policy must always change before UX. For policy optimization, isolate a cohort and one variable so the effect can be assessed.

Agree the success criterion before rollout: the intended conversion outcome, compliance, fraud, chargebacks and operational exceptions. If requesting fewer challenges improves authorization but worsens fraud loss, the conversion change alone is not sufficient evidence to retain it. Allow time for delayed risk outcomes.

Keep a control group or matched comparison where feasible, and document changes in issuer mix, traffic and provider configuration. A sandbox can verify integration cases; production outcomes are needed for conversion and risk evaluation.

For implementation detail, see Implement 3D Secure 2 for Platforms Without Losing Checkout Conversion.