3DS 工程指南：认证、授权、责任转移与风险路由

一次 3DS 交易可能完全无感，也可能要求持卡人输入 OTP、确认银行 App 通知或完成生物识别。无论界面有没有弹窗，认证结果仍要进入后续支付授权，卡组织才可能据此判断欺诈责任归属。

本文面向支付工程师、架构师和风控产品经理，沿着一笔线上卡支付拆开五个容易混淆的问题：3DS 认证了什么，Frictionless 与 Challenge 如何选择，认证与支付授权是什么关系，Liability Shift 需要哪些条件，以及 PSD2、SCA 与豁免分别处在哪一层。

先把一笔卡支付拆成四个判断

假设一位欧洲用户首次购买 120 欧元的在线订阅，交易落在强客户认证（Strong Customer Authentication，SCA）的适用范围内。一个 3ds=true 无法表达全部过程，因为链路里至少有四个独立判断：

认证成功后，发卡行仍可能因为余额不足、卡片冻结、额度或授权风控拒绝支付。支付授权成功后，持卡人也可能因未收到商品、重复扣款或服务争议发起 Dispute。3DS 主要处理持卡人认证，不能证明商户已经履约。

「三域」描述的是信任边界

3-D Secure 中的 Three-Domain 指三组参与方，与验证次数无关：

• 商户与收单域。 包括 Merchant、3DS Requestor、3DS Server、支付网关和收单机构。它们准备交易、账户与设备上下文，发起认证，并把认证结果带入支付授权。

• 互操作域。 Directory Server（DS）根据卡号范围和支付网络关系，把认证消息路由到对应的发卡行 Access Control Server（ACS）。

• 发卡域。 发卡行及其 ACS 评估交易风险，选择 Frictionless Flow、Challenge Flow，或返回拒绝、不可认证等状态。

商户可以表达认证偏好，最终路径由发卡行侧的 ACS 结合规则和风险判断决定。商户前端看到的弹窗只是 Challenge 的交互界面，不代表 3DS 的全部能力。

一笔 EMV 3DS 交易如何进入支付授权

下面继续使用首次订阅付款的例子。实际字段、可用版本和回调方式取决于卡组织、地区、收单机构与支付服务商，但主干流程保持一致。

实现时需要保留三个工程边界。

第一，AReq 的风险上下文包括金额、币种、商户、账户历史、交易关系和设备信息。应用不应把「采集了多少设备字段」当成认证质量的替代指标。

第二，Frictionless Flow 仍然完成了 3DS 认证。ACS 根据上下文自动验证持卡人，无需增加交互；风险较高、监管要求或现有信息不足时，ACS 才进入 Challenge Flow。

第三，Challenge 结束不等于支付完成。后端必须读取正式认证状态，再发起 Authorization；前端弹窗关闭、跳转返回或 App 恢复都不能作为资金结果。

Liability Shift 需要连续通过三道门

EMVCo 定义认证协议，卡组织项目规则定义具体的 Liability Shift 条件。以 Visa Secure 为例，Visa 的公开资料说明，符合规则的已认证交易或认证尝试可能发生欺诈责任转移；其他卡组织、地区、交易类型和认证状态需要分别核对，不能把这条说明扩成全网统一规则。

工程实现应记录认证证据在全链路中的连续性，并把页面是否出现 Challenge 作为单独的体验信号。建议关联以下信息：

• threeDSServerTransID、dsTransID、acsTransID 等交易标识；

• transStatus 与失败或不可认证原因；

• ECI 与卡组织要求的 Authentication Value，例如 CAVV 或 AAV；

• 3DS 版本、Device Channel、认证路径与最终结果；

• 支付服务商或收单机构返回的 Liability Shift 判定。

字段名称和取值并不跨卡组织完全一致。系统应保留服务商原始语义，并映射成内部的规范状态；普通应用日志只记录必要的关联 ID、状态和派生结果，不输出 PAN、完整 Authentication Value 或其他敏感支付数据。

责任转移的具体覆盖范围由卡组织规则定义。即使项目规则对未授权欺诈提供责任保护，未收到商品、商品与描述不符、重复扣款、取消后仍收费等问题仍需要订单、交付、退款和客户沟通证据。把 3DS 当作履约免责工具，会让 Dispute 处理在错误的证据方向上投入时间。

PSD2、SCA、3DS 与豁免处在不同层级

截至 2026 年 8 月 18 日，EUR-Lex 将 Commission Delegated Regulation (EU) 2018/389 标记为「In force」，当前合并文本日期为 2023 年 9 月 12 日。该 Regulation 要求 SCA 使用 Knowledge、Possession、Inherence 三类要素中的两个或以上独立要素，并为特定低风险或特定关系的交易提供豁免条件。

EMVCo 说明 EMV 3DS 2.0 及以上版本可以支持多种 SCA 方法和 RTS 豁免，且建议考虑 2.2 或更高版本以获得更完整的能力。无 Challenge 只能说明持卡人没有被额外打断，不能单独判断这笔交易是否满足 SCA；还要查看发卡行采用的认证方式、是否适用豁免，以及最终返回的认证结果。

现行合并文本中的低额远程支付豁免包含明确边界：单笔不超过 30 欧元，并同时受上次 SCA 之后的累计金额或连续交易次数限制。该 Regulation 还列出 Trusted Beneficiary、固定金额与固定收款人的后续 Recurring Transaction，以及 Transaction Risk Analysis 等豁免。商户不应把这些法律条件硬编码成一个跨地区通用开关；是否申请、接受或退出豁免，应由 PSP 或 Acquirer 的合规与认证引擎结合地区、牌照、欺诈率和网络规则判断。

监管豁免与 Liability Shift 需要分别判断。确定责任时还要知道由谁申请或应用豁免、认证和授权分别返回什么状态，以及对应卡组织规则如何处理该路径。

风险路由负责表达认证请求策略

一套可维护的 3DS 策略应同时读取监管范围、交易关系和欺诈风险，再向 3DS Server 或支付服务商表达认证偏好。ACS 仍保留最终认证决定权。

对高价值且交付不可逆的数字商品，即使 3DS 返回成功，商户自身风控仍需评估账户接管、设备异常和交付风险。对低风险老客，完整提交账户与交易历史可以帮助 ACS 做无感判断，但商户不能承诺一定不触发 Challenge。

可观测性要连接认证、授权与 Dispute

单看 3DS 认证成功率，无法判断它是否改善支付结果。至少需要把以下指标按地区、卡组织、BIN、Acquirer、3DS 版本和交易类型分组：

• Frictionless Rate、Challenge Rate 与 Challenge Completion Rate；

• Authentication Success Rate 与认证失败原因；

• 认证成功后的 Authorization Approval Rate；

• Soft Decline Recovery Rate 与补做认证成功率；

• Liability Shift Rate，以及各路径的欺诈和 Chargeback 结果；

• 认证耗时、Challenge 耗时和从认证到授权的端到端耗时。

状态处理也要以服务端结果为准。认证回调、浏览器返回和授权通知可能重复、延迟或乱序，系统应使用 3DS Transaction ID 与 Payment ID 做幂等关联，并阻止迟到事件覆盖已经确认的终态。3DS 超时后是否继续未认证授权，需要进入明确的风险决策；不能因为前端失败就自动降级放行。

上线前，团队应能从一笔 Payment ID 回答六个问题：是否发起 3DS、ACS 选择了哪条路径、正式认证结果是什么、认证证据是否进入授权、支付为何批准或拒绝、发生 Dispute 时卡组织最终认定的责任方是谁。缺少其中任何一段，后续对转化率、欺诈和责任转移的分析都会停在猜测。

延伸阅读

• 跨境支付：合规风控与用户运营管理
• 跨境支付：支付网关与技术方案
• 跨境支付：境外支付与外卡收单

参考资料

• EMVCo：EMV 3-D Secure

• EMVCo：EMV 3-D Secure Whitepaper V2 - Improving Risk Analysis and Frictionless Flow

• EMVCo：EMV 3-D Secure Whitepaper V2 - Challenge Flow

• Visa：3D Secure - Your Guide to Safer Transactions

• Visa：Visa Secure

• EUR-Lex：Consolidated text of Commission Delegated Regulation (EU) 2018/389

• Stripe Docs：3D Secure Authentication