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）,根据规则支持扩展,提供泛安全输入,并构建具有智能回响和可观察性的编排器-然后验证将成为盟友而不是转换制动器。