3DS2

3DS2 supplies authentication evidence for an e-commerce payment. Keep that evidence separate from the issuer's decision to authorise the payment and from its later clearing and settlement.

How 3DS2 Works

Frictionless flow: the issuer assesses data supplied through the 3DS integration, such as transaction, device and cardholder information, without requesting an additional challenge. “Frictionless” describes that authentication flow. It does not establish zero checkout latency, zero abandonment or a successful authorisation.

Challenge flow: the issuer requests further cardholder authentication, for example through a banking app or a one-time passcode. The merchant must handle completion, failure, timeout and return-to-checkout behaviour. Challenge rates and completion rates should be measured for your issuer, market and device mix; there is no universal completion benchmark here.

EMVCo describes both approaches in its deployment guidance. Send accurate supported data, rather than treating a fixed count of populated fields as an optimisation target.

The Liability Shift

Eligible 3DS transactions can shift liability for specified fraud disputes from merchant to issuer. Eligibility depends on the card network and programme, authentication outcome, transaction and correct transmission of authentication evidence with the payment. Check the PSP's reported liability-shift result and applicable exceptions; a successful authentication message alone is not a blanket guarantee.

Stripe's explanation says that non-fraud disputes remain the merchant's responsibility and that bank-approved exemption requests do not provide the authentication liability shift. Its implementation also acknowledges exceptions after successful authentication. Confirm the treatment with your own acquirer.

Illustrative distinction: a customer authenticates and later disputes the transaction as unauthorised. Eligible authentication evidence may provide fraud-liability protection. If that customer instead disputes undelivered goods, the same authentication does not establish delivery: the merchant still needs order and fulfilment evidence.

PSD2 and SCA

For transactions within the EEA PSD2/SCA scope, 3DS can support cardholder authentication. SCA scope depends on the payment and parties involved; it is not simply a rule for every purchase above a particular amount. A frictionless result is not by itself evidence that SCA was performed.

The SCA regulatory technical standards allow conditional exemptions. The remote low-value exemption has a €30 transaction ceiling and cumulative amount or consecutive-transaction conditions since the last SCA. Transaction-risk-analysis eligibility depends on the PSP's monitoring and fraud-rate requirements, with amount bands; it is not a merchant entitlement. Creating or amending a trusted-beneficiary list requires SCA. An issuer can still request authentication rather than accept a requested exemption.

Operator Checks

• Retain the authentication result and payment identifiers together, including the PSP's liability-shift indication.
• Separate exemption requests, frictionless authentication, challenges and authorisation declines in reporting.
• Test challenge completion and recovery on supported mobile and browser journeys.
• Compare approval, abandonment and fraud outcomes by cohort before claiming that a configuration improves conversion.