3-D Secure 2.0和SCA

1）為什麼iGaming運營商3DS2以及SCA是什麼

3-D Secure 2.x（EMV 3 DS）是電子商務中的持卡人身份驗證協議。
SCA（強化客戶認證）是監管要求（PSD2/UK），要求在多種情況下進行雙因素驗證。

• Liability shift：成功驗證後，欺詐風險將傳遞給發行人。
• 以上轉換Vs 3DS1：收集100多個數據元素允許無挑戰的frictionless。
• 本機腳本：用於iOS/Sandroid、in-app、decoupled和out-of-band確認的SDK。

2）角色和組件（EMV 3 DS）

3 DS Server（您有或PSP）： 將請求生成到電路,匯總數據,管理版本2。1/2.2/2.3.

目錄服務器（DS）：電路路由器（Visa/Mastercard/AmEx等）。
Access Control Server （ACS）：發行人服務器；做出決定：frictionless或challenge。
SDK/Method：收集設備信號（fingerprinting）、Web SDK/iframe和移動SDK。

3）類型UX流

3.1 Frictionless（無挑戰）

1.商人/PSP → DS：具有3 DS數據的AReq（魔法，歷史，風險信號）。
2.DS/ACS → ARes （frictionless）：身份驗證在沒有用戶參與的情況下通過。
3.接下來→授權（Auth）。

觸發時：低風險,whitelist（可信福利）,LVP,質量數據。

3.2個挑戰（挑戰賽）

1.ARes需要CReq/CRes（OTP，罐內推送確認，生物鑒定）。
2.成功→授權後，將保留liability shift。

3.3 Decoupled / Out-of-Band

銀行應用程序中的確認沒有重新引導。在移動腳本中很有用。

3.4 3RI (3DS Requestor Initiated)

用於MIT（啟動的商業）-訂閱，轉發。每個重播均沒有SCA，但需要正確引用原始CIT。

4） SCA： 在什麼地方是強制性的，在什麼地方是強制性的

強制性：如果SCA區域中的發行人和收購方，則EEA/UK中的大多數電子商務交易。
區域外/範圍外：MOTO（郵件/電話），某些公司渠道，區域間路線（發行人的TRA可能適用）。

4.1個例外（Exemptions）

TRA（交易風險分析）：提供商/銀行的低風險（由同類指標確認）。
LVP（低價值付款）：小金額,帶有發行人的門檻和計數器。
Whitelist （Trusted Beneficiary）：客戶白名單上的收件人。
Secure Corporate/Merchant Initiated （MIT）：如果有SCA的initial CIT和正確的鏈接,則SCA以後的註銷。

5） iGaming的交易標記和標誌

CIT （Customer Initiated Transaction）：主要註銷,通常需要SCA（或exemption）。
麻省理工學院回收/未註銷COF：隨後的註銷；如果與原始CIT（常規引用/ID）捆綁在一起，則不需要SCA。
PSP/Schema請求中的正確指示符對於重播中的可移動性和跳過SCA至關重要。

6）影響ACS解決方案的數據

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• 帳戶數據：帳戶年齡,最後一個密碼的日期,未成功登錄的次數。
• 交易數據：初專幹事/類別,金額/貨幣,以前的嘗試,velocity.
• Shipping/Billing：地址匹配,收件人歷史記錄。
• 3 DS方法完成指標：3 DS方法（fingerprint）是否成功完成。
• 上下文越豐富-frictionless的可能性越高。

7）與支付調配器集成流

7.1序列（web/mobile）

1.Initiate 3 DS（3 DS Server ↔ DS/ACS）→獲得ARes。
2.如果挑戰→通過SDK/iframe進行CReq/CRes。
3.成功→ Auth（授權）指定3 DS結果（ECI，CAVV/cryptogram，dsTransID）。
4.Webhook PSP → → Ledger/DWH（沒有PAN）的編排器。

7.2 Soft decline和retrai

沒有SCA的授權可以返回「soft-decline（代碼）」→從SCA重復付款。
樂團保持狀態機器嘗試：no SCA → soft decline → 3DS2 → Auth。

7.3 Multi-PSP

檢查3 DS版本（2.1/2.2/2.3), app-SDK, decoupled.

智能路由：如果部分發行商的ACS降解,則使用備用路徑（如果策略/方案允許）。

8）UX模式增強轉換

本地/SDK在移動應用中：減少重定向,更完善。
預收集數據（電子郵件，地址，行為提示）高達3 DS。
透明的等待屏幕和可理解的文本（按語言/區域本地化）。
Taymauts具有柔和的回報和重播挑戰。
Whitelisting prompt：建議客戶將商品添加到銀行信任的商品中（在可用的情況下）。

9）錯誤和極端情況

Timeout/Unavailable ACS →正確的代碼和重播（或策略倒退）。
版本降級：如果2.2/2.3不可用，回滾到兼容版本。
Partial method：如果3 DS Method未完成,仍然發送AReq-部分數據優於零。
混合流：同時3 DS+AVS地址驗證-正確地繪制狀態。
3 DS之後的Chargeback：與人工制品（ECI，CAVV，ARes/CRes refs）競爭。

10）要儲存的文件和文物

3 DS事務標識符（dsTransID，threeDSServerTransID）。
身份驗證結果（ECI，CAVV/AVV，ARes/CRes狀態）。
SDK標誌（無PII/PAN），計時器和錯誤代碼。
麻省理工學院到原始CIT的訂閱/重播鏈接。
軟約束和TRA異常處理策略。

11）度量標準與目標（iGaming的KPI）

轉化

3 DS完成率（成功完成身份驗證的比例）。
frictionless vs challenge的比例（目標是↑ frictionless）。
3 DS屏幕上的Abandonment rate。

風險

Liability shift（下面-更好）後脫衣舞。
使用3 DS進行軟解碼的份額和後續轉發的成功率。

技術

3 DS p95時間（起始→結果）。
SDK/iframe錯誤，ACS計時器。

12）發射支票清單3DS2+SCA

• 3 DS Server已連接（版本2.1/2.2/2.3），測試賓斯工作。
• Web SDK/mobile-SDK集成了（in-app+ webview腳本）。
• 啟用de-vice/browser數據收集（3 DS方法）。
• CIT/MIT/COF標記正確；存儲到原始CIT的鏈接。
• 在編排器中實現了軟調試流→與SCA的重播。
• Exemptions （TRA/LVP/whitelist）配置並計算原因/結果。
• Multi-PSP：3 DS版本和後退路徑已驗證。

[] Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.

• 3 DS和dispute-playbook工件存儲策略已準備就緒。
• 預定A/B測試UX提示（本地化、文本、定時）。

13）與PCI DSS和令牌化的關系

3DS2不能取代PCI DSS：它是關於身份驗證，PCI是關於數據保護。
對於PAN-safe：在托管場/iframe中輸入卡；樂團只看到令牌和3 DS工件（ECI/CAVV）。
對於COF/MIT，請使用network tokens或vault令牌來減少鞭打並增加授權。

14）常見問題解答簡短

是否需要始終進行3DS?在SCA區域中-是的,除非有正確的exemption/異常。發行人可以要求挑戰。
如果銀行破產？使用retrais/taymout策略,如果可能,使用不同的路線。
3 DS會增加轉換嗎?具有豐富數據的正確配置的3DS2 會增加無裂紋的比例並降低裂紋/charjbacks。
什麼是最關鍵的成功?豐富的上下文數據、正確的CIT/MIT/COF標誌、快速UX和熟練的軟處理。

15）摘要

對於iGaming來說，3DS2+SCA不是「強制性的痛苦」，而是增長工具：更微不足道，更少frods，責任轉移到發行人，訂閱和重復註銷的穩定貨幣化。放下正確的標誌（CIT/MIT/COF）,根據規則支持擴展,提供泛安全輸入,並構建具有智能回響和可觀察性的編排器-然後驗證將成為盟友而不是轉換制動器。