商户如何读懂3D Secure：身份验证与有条件的欺诈责任转移

3D Secure（3DS）提供持卡人身份验证方面的证据。验证成功本身不代表发卡行批准付款、请款成功或商户已经收到资金，也不代表所有交易争议都由其他方承担。商户应分别读取身份验证结果和支付的财务结果，再核对某一项欺诈争议是否符合相关责任安排的条件。

这份TrustFinance™指南帮助商户判断订单记录能够证明什么、还需要澄清什么。封面将身份验证、发卡行支付决定以及有条件的欺诈责任分开呈现。这是阅读证据的框架，不是3DS名称中的三个域。下文案例均为虚构，引用的服务商资料也只在其说明范围内使用。

身份验证能够说明什么

EMVCo说明，商户与发卡行会交换交易、支付方式及设备信息，用于帮助验证消费者。有的交易可以通过数据评估完成，不一定出现额外的交互验证；另一些交易则要求进一步验证。因此，没有看到一次性验证码不等于没有验证。相反，看到验证码或银行验证页面，也不能证明最后的验证结果。

应查阅实际交易已经完成的结果，并核对交易编号和时间。客户回到商店页面、提供截图，或员工记得曾出现验证页面，都不能代替与该次付款关联的结果。仅尝试验证、等待中、失败或无法验证的状态，不应因为结账流程继续就被改记为成功。

身份验证是一项控制措施，不是整份订单完全真实有效的证明。它不证明送货地址正确、商品已经送达，也不能保证客户不再投诉。EMVCo还说明，参与方仍须遵守适用的隐私要求。商户应按权限保存必要的交易参考信息，而非将银行卡秘密信息、密码或一次性验证码写入共享工作表。

把发卡行支付决定单独读取

Visa将身份验证与支付授权区分开：前者涉及身份，后者涉及交易能否根据可用资金、账户状态等情况继续。发卡行可以在身份验证结果之外，独立批准或拒绝付款。因此，“已验证”不能被自动等同于订单“已付款”。

每份订单都应找到确认发卡行决定的服务商记录；若该安排包含capture，也应核对请款结果。请款与商户出款、到账又是不同问题。获得财务授权不代表商户银行账户已有可用资金，而已记录请款成功也不保证以后不会发生争议或账务调整。

若验证页面和支付页面看似矛盾，应先比对交易参考编号，再向服务商确认当前财务状态。不要将一次尝试的验证成功，与另一次尝试的支付结果拼接使用。本指南不规定重试规则或系统接入方法；支付授权与请款的具体状态判断，由文末已有专题另行说明。

欺诈责任转移具有适用条件

Stripe在符合条件的欺诈争议范围内解释liability shift，并将其与未收到商品等其他争议原因区分。其资料并未保证3DS成功就一定转移责任。未收到商品的争议，仍需依照该原因适用的正常程序提交回复和证据；身份验证无法证明商品交付。

Trust Payments也提醒，验证成功不保证责任转移，也不保证支付授权成功。收单机构的判断条件可能变化，例外取决于参与支付的各方。应将该网页视为服务商说明，而不是全球统一合同。向实际收单机构核实：适用哪家卡组织、哪个商户账户、何种交易类型、地区以及哪一生效日期的规则。

身份验证指标，包括在提供时可见的ECI，都是需要结合上下文解释的证据。单个代码不是通用的保障凭证。应询问服务商如何解释实际结果、尝试验证或豁免、所需伴随信息及例外。不要将一家服务商的表格改造成全球通用代码表，也不要推定每份合同中豁免对责任的影响一致。

使用哪种语言不决定合同主体或法律权利。本简体中文版本不表示所有交易在当地法律下都必须使用3DS。如果服务商提供适用性指标，应保留其上下文，并在争议发生时确认当前状态。Stripe说明了例外及后续变化的可能性；先前的指标不等于永久承诺。

两个虚构案例：不同证据回答不同问题

案例甲：验证成功，发卡行却拒绝付款

假设一份虚构线上订单有已完成的成功身份验证记录，同时另有发卡行拒绝付款的结果。商户拥有验证方面的证据，却没有该次付款尝试获得财务批准的证据。不能仅因客户通过验证页面，就将订单标为已付款。员工应根据服务商记录和商户政策，先澄清状态再决定是否履约。

本案例不提供任何真实支付拒绝率、处理时长或特定服务商测试结果。若后来又有一次付款尝试，该次尝试需要自己对应的结果。第一次验证截图不能代替后续记录。订单团队应明确，当前依据的是哪一次尝试和哪一个财务决定。

案例乙：已有请款记录，但争议原因不同

再假设服务商已确认另一虚构订单请款成功。随后可能出现的一种指控，是持卡人未授权购买；另一种指控则是商品没有送达。这是两种替代情形，不是从余额中扣款两次。商户应先确认真正的争议原因，才判断相关责任条件。

在欺诈分支，应向收单机构询问该笔交易是否符合条件、哪些身份验证证据支持其判断。在未收到商品分支，应保留该程序要求的订单、物流及客户沟通证据。两个分支都不承诺争议处理成功或追回款项。Stripe还说明询问仍需回复，因此不能因为记录显示3DS就忽略通知。

决定前的四项证据核对

1. 实际身份验证结果

记录相互关联的交易编号、结果、时间及服务商解释。区分真正完成的结果，与仅显示或刚启动的交互验证。结果缺失或含糊时，应标为未知并请求澄清，而不是自行填写成功。

2. 发卡行支付结果

另行记录财务决定，以及在相关情况下的请款确认。商户出款和银行对账继续分开处理。核对所有记录是否属于相同订单及同一次尝试；身份核验成功不能补上缺失的支付结果。

3. 卡组织与收单机构的条件及限制

询问现行规则和收单安排是什么，该笔交易是否真正适用，哪些例外或缺失信息会影响结论。保留解释和日期。笼统的“安全结账”营销说法，不是针对某项争议的适用性判断。

4. 争议原因、回复期限及证据

阅读实际通知和服务商规定的期限，保存相关验证、付款、订单及交付编号，并按程序提交证据。不要从本指南、其他国家或不相干案例推算期限。明确谁负责检查通知，并通过获授权的渠道回复。

商户交接清单

• 核对各记录中的订单和付款尝试编号。
• 区分已确认结果与等待或缺失的信息。
• 阅读收单机构现行说明，包括范围和例外。
• 按实际争议原因分类，不将全部拒付都视为欺诈。
• 明确回复期限，妥善保存必要证据。
• 在有关不确定性得到澄清后，按商户政策决定履约或争议回复。

常见问题

3DS成功是否保证商户受到保护？

不保证。它是身份验证证据，付款批准和欺诈责任条件需要分别确认，非欺诈争议又是另一问题。即使已经请款，也不代表保证出款或一定赢得争议。

看不到一次性验证码，是否代表验证失败？

不一定。EMVCo说明，基于数据的评估可能不需要额外交互验证。应读取服务商实际结果。反过来，一次性验证码页面或客户声称已完成，也不能代替记录中的结果。

一手资料及适用范围

一手资料阅读日期为2026年10月22日。EMVCo提供技术背景；Visa、Stripe及Trust Payments提供卡组织或服务商说明。这些资料不能代替商户收单合同及适用规则。

• EMVCo：EMV 3-D Secure与隐私原则
• Visa：身份验证与支付授权的区别
• Stripe：验证流程、争议及责任转移
• Trust Payments：责任条件与收单例外

相关阅读

• 支付授权与请款的区别
• 结算、退款与拒付
• 商户如何核对支付网关可信度

通过TrustFinance™阅读相关证据指南，整理需要向服务商提出的问题。评价或品牌名称不能确定某笔交易的责任安排。

继续阅读TrustFinance Blog