本文是对EMV 3DS的标准架构做了一个介绍。关于3DS，不同的MPI实现也有差别，具体的流程和细节，在后续我会基于Worldpay、MPGS、Cybersource、dLocal以及国内一些收单公司的3DS服务做一个抽象，实践MPI的3DS通用流程。
在跨境信用卡支付中，很多用户都遇到过这样的场景：
输入卡号后，支付页面突然跳转到银行页面，需要输入短信验证码，或者在银行 App 中确认交易。
这一步就是信用卡支付中的身份验证机制：3-D Secure
随着支付行业的发展，这一体系已经升级为新的标准：EMV 3-D Secure
EMVCo在前面讲EMV QR code的文章有提供到过，3DS是他们的另一个标准。
EMV 3DS 不仅提高了安全性，也显著改善了用户体验，使得大部分交易可以在用户几乎无感知的情况下完成认证。
但在理解技术流程之前，需要先回答三个核心问题：
在传统的线上信用卡支付中，通常只需要三项信息：
这些信息一旦泄露，就可能被盗刷。
对于商户来说，这带来了一个非常严重的问题：欺诈拒付（Fraud Chargeback）
当持卡人发现交易不是自己发起时，可以向发卡行申请拒付。
如果交易被认定为欺诈，商户通常需要承担损失。
因此，卡组织推出了 3DS 身份验证体系，在支付过程中增加一次 发卡行参与的身份验证。
常见的验证方式包括：
通过这一机制，可以确认：
发起交易的人确实是持卡人本人。
对于商户来说，3DS 最大的价值不是验证码，而是：Liability Shift（责任转移）
当一笔交易成功完成 3DS 认证后，如果之后发生欺诈拒付，责任通常会从商户转移到发卡行。
简单理解：
没有 3DS
欺诈责任 → 商户承担
完成 3DS
欺诈责任 → 发卡行承担
因此在以下场景中，商户通常会主动开启 3DS：
对于支付公司和 PSP 来说，3DS 也是风控体系的重要组成部分。
虽然 3DS 可以提高安全性，但它也会增加支付步骤。
如果每一笔交易都强制验证，用户体验会明显下降。
因此在很多情况下，交易可以 豁免（Exemption） 3DS。
常见的豁免场景包括：
例如欧洲监管规定：30 欧元以下交易可以豁免强认证。
如果发卡行或收单行的风险评估认为交易风险较低，可以直接通过认证。
持卡人可能将某些商户标记为信任商户。
后续交易可以减少验证。
当交易设备、历史行为和交易模式都正常时，系统可能直接允许交易通过。
在 3-D Secure 架构中，整个系统被划分为三个 Domain。
Acquirer Domain 是 商户侧所在的系统域。
主要组件包括：
其中最核心的组件是 3DS Server。
3DS Server 负责：
这个域由卡组织运营。
核心组件：
Directory Server（DS）
DS 的作用：
Directory Server 通常由卡组织维护，例如：
Issuer Domain 是 发卡银行所在的系统域。
核心组件：
ACS（Access Control Server）
ACS 负责：
用户在支付过程中看到的验证码页面，通常就是 ACS 提供的，例如引言部分这个图就是EMV定义的一个设计规范，由各个发卡行实现。
在 EMV 3DS 中，交易通常会进入两种验证模式。
发卡行认为交易风险较低。
交易直接完成认证，用户不会看到任何验证页面。
目前大部分交易都属于这种情况。
这是EMV 3DS的规范，里面的几个名词都是逻辑角色，在实际支付系统里，它们的职责和部署方式是不同的。下面做一下简单的介绍：
3DS Requestor是发起3DS认证请求的实体，通常是商户或者支付公司以及收单行，例如Shopify、Stripe、Checkout等。
3DS Client是 运行在持卡人设备或商户前端环境中的组件。例如前端浏览器中的JS SDK代码。
3DS Server一般也可以称为MPI，供应服务商，用来和DS对接实现3DS交互过程中的各种接口。例如Cardinal、Netcetera(欧洲)、GPayments(亚洲)。
在全球主流的收单机构里面，每家的能力和发展线路不一样，这几个组件之间有交叉。
例如Cybersource作为Requestor使用的是Cardinal的3DS Server，同时提供了自己的SDK作为Client。
Adyen、Worldpay拥有自建 3DS Server，EMVCo 认证可以同时作为3DS Requestor、3DS Client 、3DS Server。大部分的支付公司还是
使用第三方的3DS Server。
Frictionless包含以下步骤：
开始：持卡人在消费设备上发起交易。持卡人提供身份验证所需的信息（持卡人输入或商户已存档的信息）。
1）3DS Requestor Environment收集必要的3-D Secure 信息并将其提供给 3DS Server，以便包含在AReq(Authentication Reqesut) 消息中。
信息的提供方式和来源取决于以下因素：
2）3DS Server使用持卡人提供的信息以及在3DS Requestor Environment中收集的数据，创建并向 DS 发送 AReq 消息，然后 DS 将该消息转发给相应的ACS。
3）ACS 收到 AReq 消息后，向 DS 返回 ARes(Authentication Response) 消息，DS 再将该消息转发给发起 3DS Server。
在返回响应之前，ACS 会评估 AReq 消息中提供的数据。
在Frictionless流程中，ACS 会判断无需持卡人进一步交互即可完成身份验证。
4）3DS Server将 ARes 消息的结果传递给 3DS Requestor Environment，后者随后通知持卡人。
到这一步3DS已经认证完成，可以继续发起授权请求了。
5）商户和收单机构——商户与其收单机构进行Authorisation。
6）收单机构可以通过支付网络向发卡机构处理授权，并将授权结果返回给商户。
如果发卡行认为交易风险较高，就会要求用户验证身份，例如：
挑战流程包含以下步骤：
开始：持卡人——与无摩擦流程相同。
1）3DS Requestor Environment——与无摩擦流程相同。
2）3DS 服务器通过 DS 到 ACS——与无摩擦流程相同。
3）ACS 通过 DS 到 3DS Server——与无摩擦流程相同，但 ARes消息指示需要持卡人进一步交互才能完成 身份验证。
4）3DS Server到 3DS Requestor Environment——与无摩擦流程相同，但需要持卡人进一步交互才能完成 身份验证。
5）3DS Client到 ACS——3DS Client根据 ARes 消息中接收到的信息发起 CReq 消息。具体方式取决于模型：
6）ACS 与 3DS Client——ACS 接收 CReq 消息并与 3DS Client交互，以促进持卡人交互。
具体方式取决于模型：
注：对于基于应用程序的模型，步骤 5 和步骤 6 将重复执行，直至 ACS 做出判断。
注：对于基于浏览器的模型，CRes 消息在步骤 8 之后发送。
7）ACS 通过 DS 发送至 3DS Server——ACS 向 DS 发送包含身份验证值 (AV) 的 RReq 消息，DS 随后使用从 AReq 消息中收到的 3DS 服务器 URL 将该消息路由至相应的 3DS Server。
8）3DS Server经 DS 到 ACS——3DS Server接收到 RReq 消息，并响应地向 DS 返回 RRes 消息，DS 随后将该消息路由至ACS。
3DS处理到此结束。
3DS 是现代信用卡支付体系中的核心安全机制。
它通过 三大 Domain 协同工作：
完成一次完整的持卡人身份验证。
对于支付系统来说，3DS 不仅仅是验证码，更重要的是：
随着 EMV 3DS 的普及，大部分交易已经可以在用户几乎无感知的情况下完成认证。
本文由 @Amour 原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。