概要
3DS 验证标准,更广为人知的是其品牌名称,如 Visa Secure、Mastercard Identity Check 或 American Express SafeKey,目的是减少欺诈并增强在线支付的安全性。
相较于 3DS 1.0 验证,3DS 2.0 验证 (3DS2) 引入了“无阻验证”功能,极大地优化了购物体验。它是满足欧洲[强客户认证]](https://stripe.com/guides/strong-customer-authentication) (SCA) 法规的主要银行卡验证手段,也是商家申请强客户认证豁免的关键机制。
Stripe 的支付 API、移动 SDK 和 Stripe Checkout 均支持 3DS 2.0 验证。
3DS 1.0 验证历史简介
尽管一些市场已采取了额外安全措施,例如地址验证系统 (AVS) 或 CVC 验证,但是信用卡和借记卡付款依然面临较高的欺诈风险。正是由于这种风险,客户才有权对其银行卡发生的欺诈性支付提出争议。
为应对这一挑战,卡组织于 2001 年推出了第一版 3DS 验证。如果您经常网购,可能对以下 3DS 验证流程并不陌生:在您输入银行卡信息并确认付款后,系统会将您重定向到另一个页面,您需要在此页面输入由发卡行提供的验证码或密码以确认交易。鉴于验证页面通常会显示卡组织的品牌,因此多数顾客对3DS验证的品牌名称如 Visa Secure、Mastercard Identity Check或American Express SafeKey 更为熟悉。
对商家而言,3DS 验证带来的好处是显而易见的:通过要求客户提供附加信息,您能够增加一层防欺诈保护,确保仅接收来自真实客户的银行卡支付。此外,利用 3DS 进行的付款验证可以转移责任,将因欺诈导致的退款责任从商家转移到发卡银行。这种额外的安全措施是大额交易(如机票购买)通常要求使用3DS验证的理由。
遗憾的是,使用 3DS 1.0 验证也有一些缺点:它增加了额外的付款步骤,为结账流程增添了阻碍,有时候会导致客户放弃购买。而且,许多银行依然硬性要求持卡人创建并记住自己的静态密码来完成 3DS 验证。这类密码容易遗忘,进一步增加了顾客放弃购物的可能性。
3DS 2.0 验证有什么新特点
由六大卡组织组成的 EMVCo 机构推出了新版 3DS 验证。3DS 2.0 验证(也称为 EMV 3-D Secure、3D Secure 2.0 或 3DS2)旨在通过引入干扰较少的验证和更好的用户体验来克服 3DS 1.0 验证的缺点。
无阻验证
采用 3DS 2.0 验证,商家和支付服务商能够安全地向发卡行提供每一笔交易的更多数据信息。这些信息不仅包括支付细节(如收货地址),还有上下文数据(例如客户设备ID或以往交易记录)。
持卡人银行可利用此类信息评估交易风险等级并选择做出适宜回复:
如果银行认为数据可信,足以认为是真正的持卡人正在进行购买,则交易就会采用“无阻”流程并完成验证,无需持卡人额外输入信息。
如果银行断定需要更多证据,交易则会按照“质询验证”流程进行,这会要求客户输入更多信息,对付款进行验证。
虽然 3DS 1.0 验证就已支持一定程度的局限性风险验证,但利用 3DS 2.0 验证能够分享更多数据,提高了交易的通过率,而不必要求客户额外提供信息,从而完成验证。

用 3DS 2.0 验证付款的示例流程(向后支持 3DS 1.0 验证)
即使交易按照无阻流程进行,商家也会受益于与采用质询验证流程的交易同样的责任转移优势。
更好的用户体验
相比于 3DS 1.0,3DS 2.0 验证诞生于智能手机时代,它使得银行得以通过其移动应用程序提供更新颖的验证体验(也称为“带外验证”)。现在,无需输入密码或接收短信验证码,用户只需利用移动应用中的指纹识别或面部识别等生物识别技术,即可轻松完成支付验证。我们期待越来越多的银行采纳 3DS 2.0,以促进更顺畅的支付验证流程。
在用户体验上的另一项重要提升是,3DS 2.0 验证直接将质询验证流程整合入 Web 和移动支付过程中,避免了完整页面的重定向。如今,在客户进行支付验证时,3DS 验证界面会作为结账页面中的一个弹出模块直接展示(浏览器流程),从而提供无缝且便捷的验证体验。

3DS 2.0 验证浏览器流程
如果您在构建一款应用程序,您可以用专为 3DS 2.0 验证开发的移动 SDK 来构建“应用内”验证流程,彻底避免浏览器重定向。

3DS 1.0 验证:使用浏览器重定向进行移动验证流程

3DS 2.0 验证:在应用内进行,改进了移动验证流程
3DS 2.0 验证和强客户认证
如果您在欧洲经营业务,那么对您而言,强客户认证 (SCA) 法规的实施已使 3DS 2.0 验证变得更为重要。由于该法规要求您对欧洲范围内的付款进行更多验证,而 3DS 2.0 验证会提供更好的用户体验,因此可以最大程度地减少对转化的负面影响。
此外,3DS 2.0 验证协议本身允许类似 Stripe 这样的支付服务商请求强客户认证豁免,无需对低风险付款进行验证。要求进行强客户认证的付款将必须经过这个“质询验证”流程,而豁免此认证的交易将直接通过“无阻”流程完成。但值得注意的是,如果支付服务商请求对要求 SCA 的付款给予豁免,并且通过“无阻”流程完成交易,则不能享受责任转移带来的权益。
Stripe 如何支持 3DS 2.0 验证?
Stripe 在我们的 payments API 和 Checkout 上支持通过浏览器使用 3DS 2.0 验证,让您可以针对高风险付款动态地应用 3DS 验证,让商家远离欺诈。当持卡人账户所属银行提供支持后,我们将应用 3DS 2.0 验证,在不支持新版验证的情况下则使用 3DS 1.0 验证。
如果您在构建移动应用,那么利用我们的 iOS 和 Android SDK 可以构建应用内验证流程,提供一种“原生”验证体验,不必再将您的客户重定向到您的应用之外。即使持卡人的账户所属银行尚不支持 3DS 2.0 验证,我们的移动 SDK 也将在您应用内的嵌入网页视图中动态回滚至 3DS 1.0 验证。
详细了解我们的 payments API、移动 SDK 和 Stripe Checkout,开始使用 3DS 2.0 验证。
MIT
|
对于商家发起的交易 (MIT, merchant-initiated transactions),强客户认证仅需在设置授权时执行一次,后续的商户发起交易则无需再次认证。与 SEPA 直接借记类似,MIT 将引入为期八周的无条件退款权。 |
---|---|
MOTO
|
对于邮购和电话订购 (MOTO, Mail Order Telephone Order) 交易,只要支付交易通过非电子渠道发起,就可以获得强客户认证豁免。 |
动态链接
|
在使用支付人设备通过近距离技术(如近场通信 NFC)进行电子支付交易,且强客户认证需要使用支付人设备联网的情况下,应采用能将交易动态关联到特定金额和收款人的强客户认证要素。 |
账户信息服务
|
对于在开放银行框架下提供账户信息服务的支付服务提供商,强客户认证仅需在首次数据访问时执行。不过,当客户在账户信息服务提供商的域名下访问汇总的账户数据时,至少每 180 天需要进行一次强客户认证。 |
令牌化
|
当持卡人主动参与令牌化流程时(例如,注册或更换钱包或存档银行卡解决方案中的银行卡时),令牌化流程需要应用 SCA。 |
交易监测
|
欧洲银行管理局将制定监管技术标准,规范支付服务商如何进行交易监测。这包括分析环境和行为特征(例如客户位置、消费习惯等)。通过这种分析,低风险交易可以豁免强客户验证,也就是所谓的交易风险分析豁免。 |
---|---|
SCA 豁免
|
欧洲银行管理局 (EBA) 还被授权制定关于强客户验证要求及其豁免的补充监管技术标准,这些标准将同时考虑风险导向方法和技术应用两个维度。 |
双重验证
|
用于双重验证的强客户验证因素可以来自同一类别,前提是确保这些因素之间的独立性。这意味着客户可以选择使用两个密码,或者同时使用指纹和面部识别来完成身份验证。 |
可访问性
|
支付服务商必须提供多种执行强客户验证的方式,不能仅限于智能设备,例如应当支持短信验证。 |
TSP 的责任
|
如果技术服务提供商 (TSP) 和支付计划运营方未能支持强客户验证的实施,将需要承担相应责任。这项规定的目的是推动所有参与强客户验证实施的相关方加强协作。 |
---|---|
外包
|
依赖 TSP 提供和验证 SCA 元素的支付服务提供者必须与这些 TSP 签订外包协议。EBA 将对这些外包协议制定要求。 |