3D Secure 2 认证实操：流程、豁免与责任转移

3D Secure 2 认证实操：流程、豁免与责任转移

3D Secure 2（下称 3DS2）是卡组织体系内的发卡行认证协议，用来确认一笔交易确实由持卡人本人授权。它在收银台上表现为一次额外的验证环节，在账务上表现为一条可以在争议中援引的认证记录。很多团队把它当成一个开关：开了就更安全，不开就更顺畅。真实情况要复杂得多，3DS2 是一个需要在拒付责任与转化率之间持续调参的机制，而且责任转移有严格的成立条件，不是开了就一定生效。

以下按协议演进、两条流程、责任转移、监管要求与豁免、触发策略、接入形态、双向影响、调优监控八个部分展开。所有涉及卡组织规则、发卡行策略与监管解释的细节，均以各卡组织现行规则、发卡行与收单机构的实际配置为准。本文只描述结构与量级，不给出具体门槛数值。

一、3DS2 与旧版 3DS1 的本质区别

3DS1 的核心是跳转发卡行页面加输入静态密码。它在结构上只有两种结果：验证通过或者验证失败，没有中间状态。这带来两个问题。第一，所有交易都要走一次整页重定向，移动端与 App 内场景体验很差，中途放弃的比例很高。第二，上送的风控信息极少，发卡行基本只能看到一个金额和一个商户名，无法区分老客复购与刚被撞库的卡，于是只能一刀切地要求验证。

3DS2 改的是数据面与交互面。数据面上，认证请求可以携带数十个交易与会话字段，包括设备指纹、收货信息、账户历史、浏览器或 App 环境特征等，发卡行据此做基于风险的决策（risk-based authentication，RBA），对低风险交易直接放行。交互面上，3DS2 不再强依赖整页跳转，支持在商户页面内嵌挑战窗口，原生 App 可以通过 SDK 完成认证，挑战形式也从静态密码扩展到一次性密码、生物识别、银行 App 内确认等。

还有一个容易被忽略的差别：3DS2 的报文是结构化的，认证结果会以明确字段回传给收单方，其中包含用于授权校验的认证值。这个认证值是责任转移能否成立的凭据，字段丢失或错传，等于认证白做。旧协议的黄昏期已经结束，主流卡组织早已停止对旧版本的支持，仍在对接旧版本的通道通常表现为认证失败率异常，这类问题要在接入层排查，而不是在业务层调参数。

二、两种流程：frictionless 与 challenge

3DS2 的第一层分叉是 frictionless 与 challenge。frictionless 指商户端与发卡行之间完成了一轮数据交换与风险判断，但没有向持卡人展示任何额外验证界面，用户体验与普通支付没有区别。challenge 指发卡行要求持卡人完成一次交互验证，形式由发卡行决定，商户只能决定是否接受这个要求。

frictionless 不是跳过认证，它同样产生完整的认证结果与责任转移效力，只是持卡人没有被要求做任何动作。这一点经常被误解：不少团队以为只有弹出验证窗口才算真的做了 3DS，于是在配置上强推 challenge，白白损失了转化率，而责任转移并没有因此变得更强。

challenge 侧真正要看的不是是否出现，而是是否完成。一次挑战从发起、用户提交到发卡行返回结果，中间有超时、跳转丢失、用户放弃等多个失血点。移动端尤其明显：挑战窗口如果不落在应用内，而需要跳到外部浏览器，回跳链路经常断裂。3DS2 的 SDK 方案与带外确认（decoupled，持卡人在另一个设备或银行 App 上确认）就是为了缩短这条链路而设计的。

上表第三行是很多团队的真实故障点。挑战发起后用户切到银行 App 完成验证，浏览器标签被系统回收，回跳请求没有发出，商户侧只看到"未收到回调"。这类问题在协议层解决不了，要在前端状态机与回调补捞机制上解决，思路可参考 支付回调框架实现指南。

三、责任转移到底转移了什么

责任转移（liability shift）指的是：当一笔交易被判定为持卡人未授权的欺诈交易并产生拒付时，原本由商户或其收单机构承担的损失，按卡组织规则转移到发卡行一侧。它转移的是欺诈类拒付的财务责任，不是所有拒付。商品未收到、货不对板、重复扣款这类争议不在责任转移范围内，依然要靠履约证据去应诉，举证方法见 拒付原因码与举证手册。

3.1 责任转移的成立条件

责任转移不是开了 3DS 就自动生效，它有一组必须同时满足的条件。

第一，认证必须真实完成。frictionless 结果也算完成，但前提是认证结果标识明确为已认证，而不是尝试认证或未认证。

第二，授权请求必须与认证请求金额一致。这是最常出错的环节：用户在收银台先看到预估金额，随后加购、加运费、用优惠券，实际授权金额与认证时的金额不同。金额不一致时，卡组织规则一般不允许商户援引责任转移，即便认证本身成功了。有的实现会在金额变化后重新发起认证，有的干脆放弃转移，两种做法要看业务取舍。

第三，认证凭据必须被正确传递。认证过程中生成的认证值需要随授权请求一起上送，任何环节丢弃或格式错误，发卡行都无法校验，责任转移随之失效。

第四，交易必须走认证过的通道。用非认证通道补单、用离线授权、用测试凭据重放，都不会产生转移效力。

把这四条记牢，就能解释一个典型错觉：为什么 3DS 覆盖率很高，欺诈拒付仍然由自己承担。答案往往在金额不一致或者认证值丢失上，而不是在认证开关本身。

四、PSD2 的 SCA 要求与豁免类型

在欧盟经济区，3DS 不只是可选项，它还承载着 PSD2 下的强客户认证（Strong Customer Authentication，SCA）义务。SCA 的实质要求是：电子支付在发起时，至少使用三类要素中的两类来验证身份，三类分别是持卡人知道的东西（知识）、持有的东西（持有）、本身具有的特征（生物特征）。静态密码加短信验证码的组合，就属于知识与持有的组合。

监管在制定规则时也承认，逐笔强制 SCA 会显著损伤线上支付体验，因此给出了一组豁免类型。豁免的本质是把风险判断权交给某一方，谁获得判断权，谁就承担对应的欺诈责任，这一点在策略选择里非常关键。

上表只列名称与适用逻辑。具体金额门槛、累计笔数、评分参考值与各市场落地差异，均以监管原文、卡组织规则与收单机构的实际配置为准，本文不给出数值。需要提醒的是，豁免不等于零风险，尤其是主动申请交易风险分析的团队，省下了验证摩擦，换来的却是自己承担欺诈损失的敞口。

五、什么时候该触发、什么时候该豁免

这是 3DS 策略里最需要业务判断的部分。先给一个反直觉的结论：欺诈率高、客单价高的业务，主动触发 3DS 往往提升整体收益；低客单价、老客复购为主的业务，过度触发会显著伤害转化率。

前者容易理解。客单价高意味着单笔欺诈损失大，拒付处理成本也高，一次成功的责任转移可能抵得上很多笔交易的认证摩擦成本。后者正好相反：单笔金额低，欺诈损失的绝对值小，而每一次挑战都在真实地赶走一部分本来会付款的老客，长期累计是净亏损。

中间地带要靠数据说话，可用的判断口径有三个。第一是按客群分层看认证前后的表现：新客、首单、异地收货、金额显著高于历史均值的订单，风险信号多，倾向触发；老客、稳定收货地址、历史零拒付的账户，倾向豁免。第二是按通道看：不同收单方上送的字段丰富度不同，字段越全，frictionless 命中率越高，触发成本越低。第三是按品类看：虚拟商品、即时交付、易转售的品类，欺诈变现速度快，应更保守。

还有一层容易被漏掉的规则是豁免的责任归属。如果你使用交易风险分析豁免，交易在没有挑战的情况下通过，欺诈损失留在自己这边；如果你主动要求挑战并成功完成，责任转移到发卡行。所以豁免与挑战不是体验与安全的二选一，而是谁承担损失的选择。风控策略的整体框架可参考 支付欺诈防范策略。

六、接入方式：收单方托管还是自成报文

接入层有两种典型形态。第一种是收单方或支付网关托管 3DS 能力：你调用网关接口时附带 3DS 相关参数，网关作为 3DS Server 与目录服务器、发卡行侧组件交互，把挑战地址或认证结果返回给你，你负责把用户送到位并处理回调。第二种是自成报文：你自己或通过专门的 3DS 平台承担 3DS Server 角色，直接对接目录服务器，自己维护协议版本、报文签名与认证流程。

托管形态的优点是上线快、维护成本低，协议升级由服务商负责，你只需处理业务参数与结果。缺点是策略颗粒度受限：哪些字段上送、什么条件下申请豁免、挑战窗口如何渲染，通常只能通过服务商开放的能力调整。它适合绝大多数中小团队与快速上线的场景。

自成报文形态的优点是控制力强，可以针对每一类交易精细决定上送字段与豁免申请，也便于把自有风控信号注入流程。代价是门槛与成本：3DS Server 通常需要通过卡组织的合规认证，协议版本演进要持续跟进，报文与签名出错时的排查责任全在自己。它适合交易量大、风控体系成熟、有专门支付团队的组织。

第三种形态常被忽略：原生 App 的 SDK 接入。它不属于上面两类的前端形态，而是把挑战收进 App 内，避免跳转外部浏览器造成的断链。做 App 业务的团队应优先评估 SDK 方案。无论哪种形态，都要注意沙箱与生产环境的凭据隔离，联调方法见 支付网关沙箱测试。

七、3DS 对成功率与拒付的双向作用

3DS 对两个核心指标的作用方向是相反的，这是所有调优工作的出发点。

对拒付，方向是下降。一部分盗卡交易在发卡行验证环节就被拦下，根本不会进入授权成功阶段；即使有漏网的欺诈交易产生拒付，只要认证真实完成且金额一致，损失会转移到发卡行。所以 3DS 同时降低了欺诈拒付的发生率与单次拒付的净损失。

对成功率，方向通常是下降。挑战本身是额外操作步骤，必然带来放弃；挑战窗口的跳转、加载、超时也会产生技术性失败；还有一部分交易会在发卡行侧因为验证不通过而被拒绝，而在不做 3DS 的情况下这些交易可能本来会通过。

所以正确的评估口径不是开了 3DS 成功率跌了多少，而是把四项放在一起算净收益：欺诈损失减少、拒付处理成本减少、责任转移带来的损失回收、转化与认证失败带来的收入减少。四项相抵为正，就应该扩大触发范围；为负，就应该收紧到只覆盖高风险交易。这个计算没有通用答案，必须用自己的订单数据算，口径可参考 支付成功率优化指南 与 退款与争议处理指南。同时，卡数据安全与合规边界仍需单独评估，见 PCI DSS 合规实务。

八、参数调优与监控清单

调优的前提是能观测。3DS 的很多问题在日志里是看不见的：用户放弃挑战只是一个未完成的订单，不会产生任何错误码。因此必须在上线前把观测点布好，否则调优只能靠猜。

8.1 监控节奏与责任人

上线首周按天看，重点看认证技术失败与挑战完成率；稳定后按周看，重点看欺诈拒付的分布变化；每次大促、每次收银台改版、每次新增市场或卡种之前，都要重新审视触发规则。责任人应明确到风控与支付的交叉角色，避免出现策略没人负责、指标没人解释的状态。

与通道选型和资质相关的判断，可参考 支付合规与备案资质指南；若正在规划更换通道，整套流程见 支付通道迁移实操。常见支持 3DS2 的通道包括 Adyen、Stripe、Checkout.com 与 Braintree，区域覆盖可再看 Nuvei 与 dLocal。更多支付方案可参见 支付 分类。

来源：16IDC 原创，文中涉及的产品能力、费率与准入要求以相关服务商官网文档及合同为准。