3DS总结
- 3DS，即Three Domains Secure，Three Domain分别是： 发卡机构域 、 收单方域 (收款行、商家)、 互操作域 (卡组及其基础设施，网络等)。
- 本质上是一种协议，主要用于持卡人身份验证以降低交易欺诈的风险，协议中并没有规定验证的手段，发卡行可自行制定。3DS 1.0主要是通过静态密码或OTP验证；3DS 2.0主要通过传递的设备信息、订单相关信息、交易历史记录、生物识别、OTP等方式验证；
- 3DS协议有两个版本，分别为1.0跟2.0。
1.0是早期版本比较落后，每一笔交易都要重定向到浏览器进行验证，对用户有干扰，这类有感支付成单率低，而且有被引导到钓鱼网站的风险；
2.0是目前最新标准，它增强安全性的同时还简化了身份验证流程，优化支付体验。2.0能携带比1.0更多的上下文信息（如设备、订单、交易历史等，几十个字段），这些上下文信息大部分情况下足以让风控判断此笔交易是否具有欺诈风险，若无风险则通过认证，若有风险则要求更进一步的验证：生物识别或OTP等。这也分别对应两种认证流程：无摩擦认证( Frictionless Flow )和挑战认证( Challenge Flow )。
3DS认证介绍
- 3DS(3-Domain Secure)，也称为付款人身份验证，是一种有助于防止在线信用卡和借记卡交易中欺诈的安全协议。此安全功能由Visa和Mastercard支持，并分别被标记为Verified by Visa/Visa Secure和Mastercard SecureCode/Mastercard Identity Check。
- Thredd使用Cardinal Commerce作为我们的3D安全服务提供商。Cardinal提供实时3D安全注册和身份验证服务，称为实时数据交换（RDX）。您可以通过Thredd实现这项服务，以确保您的持卡人成功注册并使用3D Secure进行身份验证
- 3DS允许发卡行对无卡（cardnot present = CNP）交易发生期间验证（authenticate）其持卡人。在这种情况下交易，对于欺诈转换的责任从商户转移到发卡行，从而减少对商家的退单（chargeback）。要想使用3DS，持卡人需要首先在其发卡行完成一次性的注册过程并激活3DS服务。在交易时，持卡人浏览器接收到一个弹出窗口要求持卡人输入密码等信息，以便发卡行对持卡人进行认证。
- 您可以配置 Cardinal 用于无障碍支付身份验证批准决策的规则，以及触发进一步身份验证请求的 challenge（挑战）规则
3DS 1.0简介
- 对于商家来说，3DS 验证的优势很明显：要求客户提供额外信息让您可以构建一层额外欺诈保护，确保您只接收来自合法客户的银行卡付款。还有一项优势是，采用 3DS 验证对付款进行验证可转移责任，将因欺诈而产生的撤单责任从商家转移到客户的账户所属银行。此项额外保护就是大额付款（例如购买机票）通常采用 3DS 验证的原因。
- 3DS v1.0在结帐过程中增加了一个额外的步骤，使支付交易过程复杂化。 在结帐期间，持卡人需要在单独的弹出窗口中输入他的密码或者注册3DS服务（如果以前没有这样做的话）。这会中断对客户购买过程，扰乱了客户，并且可能导致转化率（点击/购买）的降低。 此外，3DS v1.0仅支持基于浏览器的支付，而不支持APP内发起的支付。
- 当实施3DS v1.0时，商户可以受益于对3DS授权交易的欺诈责任从商户到发卡行。另一方面，商户需要投资额外的组件，甚至可能增加其PCI-DSS认证的范围。 此外，由于结账过程的复杂性而降低转换率的风险使一些商户愿意实施3DS。
- 最后，3DS v1.0可能容易受到网络钓鱼和“中间人”攻击。因为3DS交易过程中会，系统要求重定位到另一个URL。 攻击者可以生成类似的弹出窗口，可以在客户的计算机上窃取个人信息或*载下**恶意内容
3DS 2.0简介
为了应对上述讨论的挑战并适应当前和未来的市场需求，3DS规范已经被更新。 此更新的目的是增强安全性，支持基于应用程序内（In-APP）的身份验证，并提升持卡人在结帐过程中的用户体验。 2016年10月，在拉斯维加斯举行的20/20金钱大会期间，EMVCo发布了版本号为2.0（3DSv2.0）的3-D Secure新规范。 EMVCo 是一个由六大卡组织组成的机构，他们推出了新版 3DS 验证。3DS 2.0 验证（也称为 EMV 3-D Secure、3D Secure 2.0 或 3DS2）旨在通过引入干扰较少的验证和更好的用户体验来克服 3DS 1.0 验证的缺点。
与3DS v1.0相比，3DS v2.0增强的主要功能有：
- 支持在手机和其他客户设备上的应用内（In-APP）支付。
- 允许商户将身份验证过程集成到结算体验中，并适用于基于应用（In-APP）和基于浏览器的实施。
- 使发卡行能够对交易授权执行基于风险的决策，从而在客户不需要与发卡行之间做额外身份验证从而实现无摩擦的持卡人身份验证。 启用非付款客户验证，允许他们使用诸如移动钱包的识别和验证（ID＆V）等服务，或令牌请求的安全保证服务。
- 3DS v1.0和3DS v2.0之间的另一个显着区别是，3DS v2.0开发标准包括了主要的全球卡品牌，如American Express，Discover，JCB，Mastercard，银联UnionPay和Visa。 3DSv2.0专注于交互性，不仅是跨卡种，而是跨电子商务和移动商务的。 此外，3DS v2.0可以支持Payment Service Directive 2 （PSD2），对于基于应用程序和浏览器的支付交易，它要求使用严格的客户身份验证。 3DS v.2.0允许这两种类型的付款交易，因此3DS v2.0的实现可能对商户和发卡行都带来帮助。
Thredd 3DS 认证处理流程
持卡人身份一旦认证成功，商户会发起一笔授权交易请求。商户收单机构在交易请求中包含从 Cardinal 收到的 3DS 安全值： UCAF 字段（对于 Mastercard）和 CAVV 字段 （对于 Visa），如果Thredd收到请求，Thredd将验证AAV（Mastercard）或CAV（Visa）。如果您需要Thredd来验证CAVV或AAV，请在填写3DS产品设置表时，选择YES。
什么AAV？
- 在 3DS（3-D Secure）身份认证中，"AAV" 是指 "Accountholder Authentication Value"，即账户持有人认证值，是用于指示卡片持有人在特定交易中已经通过身份认证的临时值。3DS 是一种用于在线信用卡支付安全的协议，旨在增强信用卡交易的安全性，减少欺诈风险
- AAV 是 3DS 协议中的一个重要元素，用于验证卡片持有人的身份。当进行 3DS 身份认证时，卡片持有人可能需要输入一些额外的信息，例如密码、验证码、或通过其他方式进行身份验证。通过验证后，将生成一个 AAV，表示账户持有人认证值。
- AAV 通常是一个临时的、动态生成的值，用于指示持卡人在特定交易中已经通过了身份认证。支付网关或服务提供商将 AAV 包含在交易数据中，以便商户和银行可以识别已经通过 3DS 身份认证的交易，从而增加交易的安全性。
Thredd 支持5种身份验证类型
- Risk based authentication (RBA)： 基于风险的身份验证。身份验证决策是基于Cardinal规则完成的，该规则生成一个风险评分，用于确定是批准还是拒绝交易。这个过程由Cardinal负责管理。
- OTP SMS authentication： OTP短信身份验证。Cardinal生成一次性密码（OTP）。Thredd通过短信将OTP发送到持卡人的手机号码，持卡人在3D安全屏幕中输入OTP以验证电子商务交易。
在使用OTP之前，你需要在卡上设置OTP凭证. 查阅api: Using the Card Enrolment API.
- 持卡人在商户网站上使用他们的卡进行交易支付
- 如果商户注册了3D Secure服务, 他们发送认证请求到卡组 (Mastercard/Visa)
- 卡组查找3DS服务提供商同时发送认证请求给Cardinal
- Cardinal检查确认这些卡BIN启用了3DS服务. 基于你的卡应用程序在 Cardinal设置的规则，这个结果可能是 Success, Fail/Reject or Challenge. (See Appendix 1: Cardinal 3D Secure Rules)
- 对于Success结果, 返回同意结果给商户. 他们后续会继续处理交易授权流程。
- 对于Fail/Reject结果, 返回认证失败或者拒绝结果给商户. 他们可能决定是否继续询问持卡人提供另外一种支付方式。
- 对于challenge结果, 3D Secure 认证必须存在，可以看下面的步骤流程：
- Challenge结果处理步骤流程：
- Cardinal连接Thredd实时查询被注册信用卡的认证类型 (例如： Biometric, OTP SMS or KBA)
- Thredd 返回信用卡上注册的OTP的认证类型给 Cardinal (基于Web Services/ Cards API注册的认证类型和默认为卡设置的认证类型)
- Cardinal 生成OTP一次性验证码，并发给Thredd.
- Cardinal 向持卡人展示OTP输入页面
- Thredd 发送OTP验证码给持卡人手机sends the OTP to the cardholder’s mobile number.
- 持卡人输入OTP验证码完成身份验证
- Cardinal校验OTP验证码并将验证结果返回给商户
Biometric authentication： 生物识别身份验证。Cardinal向Thredd发送生物识别身份验证请求，我们将其转发到您的系统。您需要使用客户的智能手机应用程序，通过从持卡人的移动设备获取的指纹扫描或人脸识别等生物识别数据来验证持卡人。您的客户应用程序管理生物识别验证并向Thredd返回响应。
- 在使用BIOMETRIC认证之前 , 你需要设置卡的身份认证类型为BIOMETRIC，前面的1-5个步骤和上面一样
- Thredd 返回Biometric身份认证类型给Cardinal
- Cardinal 调用Thredd 启动 Biometric认证
- Thredd发送消息到 RDX 服务接口, 使用Biometric开启身份认证。 Program Managers必须在5s内调用Thredd的 NotifyInitiateAction API 请求(200 OK) ，因为 Cardinal 期望在5s内响应处理。
- Cardinal 向持卡人展示Biometric身份认证页面. 同时通知持卡人需要使用你的智能设备app进行认证。
- 你通过客户的智能设备App内应用连接到你的持卡人。
- 持卡人使用智能设备进行生物识别身份认证 (例如 通过指纹或者扫描人脸)
- 当认证完成时将会进行如下处理:
- 你的app必须向Thredd返回生物识别认证的结果
- 你的app必须回调商户app页面url重定向到持卡人到商户的结算页面.
- Cardinal 发送校验请求到Thredd.
- Thredd 等待你的校验响应结果(NotifyValidate API) ，同时将结果返回给Cardinal
- Cardinal 返回结果给merchant
Out of Band (OOB) authentication ：外部身份验证。Cardinal向Thredd发送身份验证请求，我们将其转发到您的系统。您需要使用客户的In-AppClosed智能手机应用程序验证持卡人，例如要求他们输入用户名和密码。您的客户应用程序管理验证并向Thredd返回响应。
Knowledge Based Authentication (KBA)： 基于知识的身份验证（KBA）。您使用3D Secure RDX服务在KBA中注册卡，并提供安全问题ID和答案。Thredd为Cardinal提供了用于KBA的安全问题。在电子商务身份验证会话期间，Cardinal要求持卡人回答安全问题，然后向Thredd发送KBA身份验证请求以及持卡人的回答。Thredd将Cardinal返回的答案与存储在Thredd数据库中的答案进行比较，然后将响应返回给Cardinal。KBA通常与OTP短信相结合：持卡人首先被要求使用OTP进行身份验证，然后通过KBA进行身份验证。
在使用KBA身份认证之前, 你需要设置KBA认证方式,在KBA认证的会话中还包括针对卡交易身份认证问题和答案，在线身份认证方式使用KBA认证通常回结合 OTP SMS认证方式; the KBA 认证一般在OTP SMS认证之后
- Cardinal连接Thredd实时查询注册的卡的认证类型 (例如： OTP SMS and KBA)
- Thredd 返回 OTP and KBA的认证类型给 Cardinal. 对于KBA认证类型, Thredd还会返回持卡人设置的安全问题
- Cardinal 首先处理OTP SMS认证方式, 向持卡人呈现OTP验证码页面, 客户输入由Thredd发送到他们手机的OTP验证码
- OTP验证完成后, Cardinal 向持卡人展现另一个页面，让他们回答在卡上设置的安全问题
- 持卡人输入他们设置问题的答案
- Cardinal 校验OTP验证码，同时提交OTP验证结果和KBA问题回答到Thredd
- Thredd拿在数据库中存储的答案和由Cardinal 提交的问题答案进行比较 。Thredd 返回OTP和KBA的校验结果给 Cardinal
- Cardinal返回校验结果给商户