3-D Secure 2. 0 and SCA

1) Why the iGaming operator 3DS2 and what SCA is

3-D Secure 2. x (EMV 3DS) - card holder authentication protocol in e-commerce.
SCA (Strong Customer Authentication) is a regulatory requirement (PSD2/UK) that requires two-factor verification in a number of scenarios.

• Liability shift: with successful authentication, the risk of fraud passes to the issuer.
• Above conversion vs 3DS1: collecting 100 + data elements allows frictionless without challenge.
• Native scripts: SDK for iOS/Android, in-app, decoupled and out-of-band confirmation.

2) Roles and Components (EMV 3DS)

3DS Server (with you or PSP): generates requests to the diagram, aggregates device data, manages versions 2. 1/2. 2/2. 3.
Directory Server (DS): scheme router (Visa/Mastercard/AmEx, etc.).
Access Control Server (ACS): issuer server; makes a decision: frictionless or challenge.
SDK/Method: collection of device signals (fingerprinting), web-SDK/iframe and mobile-SDK.

3) Typical UX streams

3. 1 Frictionless (no challenge)

1. Merchant/PSP → DS: AReq with 3DS data (device, history, risk signals).
2. DS/ACS → ARes (frictionless) - authenticated without user intervention.
3. Next → Auth.

When it works: low risk, whitelist (Trusted Beneficial), HDL, quality data.

3. 2 Challenge (with challenge)

1. ARes requires CReq/CRes (OTP, push confirmation at the bank, biometrics).
2. After success, authorization →, liability shift is saved.

3. 3 Decoupled / Out-of-Band

Confirmation in the bank application without redirect. Useful in mobile scenarios.

3. 4 3RI (3DS Requestor Initiated)

Used for MIT (merchant-initiated transactions) - subscription, retray. There is no SCA on each replay, but a valid reference to the initial CIT is required.

4) SCA: where mandatory and where valid

Required: most e-commerce transactions in EEA/UK if the issuer and acquirer are in the SCA zone.
Out-of-scope: MOTO (mail/phone), some corporate channels, inter-zone routes (issuer's TRA may apply).

4. 1 Exceptions

TRA (Transaction Risk Analysis): low provider/bank risk (confirmed by fraud metrics).
LVP (Low-Value Payments): small amounts, with issuer thresholds and counters.
Whitelist (Trusted Beneficial): The recipient in the client's whitelist at the issuer.
Secure Corporate/Merchant Initiated (MIT): subsequent write-offs outside of SCA if there is an initial CIT with SCA and correct references.

5) Transaction marking and flags for iGaming

CIT (Customer Initiated Transaction) - initial write-off, usually requires SCA (or expiration).
MIT Recurring/Unscheduled COF: subsequent write-offs; do not require SCA if there is a link to the original CIT (inter-merchant links/identifiers).
Correct indicators in PSP/schema requests are critical for liability shift and SCA skipping on replicates.

6) Data affecting ACS solution

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• Account data: account age, last password date, number of unsuccessful logins.
• Transaction data: MCC/category, amount/currency, previous attempts, velocity.
• Shipping/Billing: address match, recipient history.
• 3DS method completion indicator: did 3DS Method (fingerprint) have time to work out.
• The richer the context, the higher the chance of frictionless.

7) Payment orchestrator integration flows

7. 1 Sequence (web/mobile)

1. Initiate 3DS (3DS Server ↔ DS/ACS) → receive ARes.
2. If the challenge → run CReq/CRes through the SDK/iframe.
3. Auth → success (authorization) with 3DS result (ECI, CAVV/cryptogram, dsTransID).
4. Webhook PSP → orchestrator → Ledger/DWH (without PAN).

7. 2 Soft-decline and retrai

Authorization without SCA can return 'soft-decline (code)' → repeat the payment with SCA.
Orkestrator holds the state-car of attempts: no SCA → soft-decline → 3DS2 → Auth.

7. 3 Multi-PSP

Check support for 3DS versions (2. 1/2. 2/2. 3), app-SDK, decoupled.
Smart-routing: if ACS degrades in some issuers, use a backup path (if policies/schemes allow).

8) UX patterns that boost conversion

Native/SDK in mobile applications: fewer redirects, higher completeness.
Pre-collect data (e-mail, address, behavioral signals) up to 3DS.
Transparent waiting screens and clear texts (localization by language/region).
Timeouts with soft return to payment and repeat challenge.
Whitelisting prompt: offer the client to add merchant to the bank's trusted ones (where available).

9) Errors and extreme cases

Timeout/Unavailable ACS → correct codes and repetition (or fallback by policy).
Version downgrade: if 2. 2/2. 3 not available, rollback to compatible version.
Partial method: if the 3DS Method has not completed, still send AReq - better partial data than zero.
Mixed flows: simultaneously 3DS + AVS address verification - correctly map statuses.
Chargeback after 3DS: Dispute with artifacts (ECI, CAVV, ARes/CRes refs).

10) Documents and artifacts to keep

3DS Transaction IDs (dsTransID, threeDSServerTransID).
Authentication results (ECI, CAVV/AVV, ARes/CRes statuses).
SDK logs (without PII/PAN), timestamps and error codes.
MIT links to the initial CIT for subscriptions/repeats.
Soft-decline and TRA exception handling policies.

11) Metrics & Goals (iGaming KPIs)

Conversion

3DS completion rate.
Share of frictionless vs challenge (target - ↑ frictionless).
Abandonment rate on 3DS screens.

Risk

Fraud rate after liability shift (below - better).
Share of soft-decline and success of subsequent retrays with 3DS.

Technique

Time 3DS p95 (initiation → result).
SDK/iframe errors, ACS timeouts.

12) 3DS2 + SCA start checklist

• 3DS Server connected (version 2. 1/2. 2/2. 3), test beans worked out.
• Web SDK/Mobile SDK integrated (in-app + webview scripts).
• De-vice/browser data collection is enabled (3DS Method).
• CIT/MIT/COF markings are correct; a link to the initial CIT is stored.
• Soft-decline thread → repetition with SCA is implemented in the orchestrator.
• Exposures (TRA/LVP/whitelist) are configured and reasons/results are logged.
• Multi-PSP: 3DS versions and fallback path verified.
• Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.
• 3DS artifact retention policies and dispute playbooks are ready.
• A/B UX hint tests (localization, texts, timeouts) are scheduled.

13) Relationship with PCI DSS and tokenization

3DS2 does not replace PCI DSS: it is about authentication, and PCI is about data protection.
For PAN-safe: entering the card in hosted fields/iframe; the orchestrator sees only tokens and 3DS artifacts (ECI/CAVV).
For COF/MIT, use network tokens or vault tokens to reduce fraud and increase authorization.

14) FAQ short

Do I always need to do 3DS? In an SCA zone, yes if there is no valid expiration/exception. The issuer may require a challenge.
If the bank broke? Use retray/timeout policies and, if possible, another route.
Will 3DS give an increase in conversion? A properly configured 3DS2 with rich data increases the proportion of frictionless and reduces fraud/chargebacks.
What is most critical to success? Rich contextual data, correct CIT/MIT/COF flags, fast UX and competent soft-decline processing.

15) Summary

For iGaming, 3DS2 + SCA is not a "mandatory pain," but a growth tool: more frictionless, less fraud, transfer of responsibility to the issuer, stable monetization of subscriptions and repeated write-offs. Lay down the right flags (CIT/MIT/COF), support excerpts according to the rules, provide pan-safe input and build an orchestrator with smart retraces and observability - then authentication will become an ally, not a brake on conversion.