一文看懂银行卡的3DS 2.0机制!

一文看懂银行卡的3DS 2.0机制!
2017年01月10日 20:16 支付头条

电子商务的发展为我们提供了更方便的服务和支付方式,导致无卡(card not present)交易的数量大幅增加。同时,这种增长意味着这一领域的欺诈活动同样也在快速增长。商户不得不为欺诈交易承担最终的责任。发卡行必须花费大量资源来处理退单(chargeback)流程。

界对这些挑战的对应是引入3-D Secure(3DSv1.0)机制。第一版本的3DS是由Visa开发的一套安全标准,其他卡组织也总体上支持这个机制。我们可以通过卡组织定义的品牌名字识别它们:“Verified by Visa”, “MasterCardSecureCode”。

3DS允许发卡行对无卡(cardnot present = CNP)交易发生期间验证(authenticate)其持卡人。在这种情况下交易,对于欺诈转换的责任从商户转移到发卡行,从而减少对商家的退单(chargeback)。要想使用3DS,持卡人需要首先在其发卡行完成一次性的注册过程并激活3DS服务。在交易时,持卡人浏览器接收到一个弹出窗口要求持卡人用例如输入密等信息,以便发卡行对持卡人进行认证。

3DS V1.0面临的挑战

虽然3DS v1.0有助于减少欺诈的数量,并为持卡人和商户提供额外的安全保障层,但它并不能解决所有的问题。首先,3DS在结帐过程中增加了一个额外的步骤,使支付交易过程复杂化。 在结帐期间,持卡人需要在单独的弹出窗口中输入他的密码或者注册3DS服务(如果以前没有这样做的话)。这会中断对客户购买过程,扰乱了客户,并且可能导致转化率(点击/购买)的降低。 此外,3DS v1.0仅支持基于浏览器的支付,而不支持APP内发起的支付。

当实施3DS v1.0时,商户可以受益于对3DS授权交易的欺诈责任从商户到发卡行。另一方面,商户需要投资额外的组件,甚至可能增加其PCI-DSS认证的范围。 此外,由于结账过程的复杂性而降低转换率的风险使一些商户愿意实施3DS。

最后,3DS v1.0可能容易受到网络钓鱼和“中间人”攻击。因为3DS交易过程中会,系统要求重定位到另一个URL。 攻击者可以生成类似的弹出窗口,可以在客户的计算机上窃取个人信息或下载恶意内容。

3-D Secure v2.0简介

为了应对上述讨论的挑战并适应当前和未来的市场需求,3DS规范已经被更新。 此更新的目的是增强安全性,支持基于应用程序内(In-APP)的身份验证,并提升持卡人在结帐过程中的用户体验。 2016年10月,在拉斯维加斯举行的20/20金钱大会期间,EMVCo发布了版本号为2.0(3DSv2.0)的3-D Secure新规范。

与3DS v1.0相比,3DS v2.0增强的主要功能有:

•支持在手机和其他客户设备上的应用内(In-APP)支付。

•允许商户将身份验证过程集成到结算体验中,并适用于基于应用(In-APP)和基于浏览器的实施。

•使发卡行能够对交易授权执行基于风险的决策,从而在客户不需要与发卡行之间做额外身份验证从而实现无摩擦的持卡人身份验证。 启用非付款客户验证,允许他们使用诸如移动钱包的识别和验证(ID&V)等服务,或令牌请求的安全保证服务。

典型交易:3DSV1.0 VS 3DS V2.0

3DS v1.0和v2.0之间的交易流有很多不同。每个版本的典型交易流程如下图所示。以下是对系统组件,流和消息传递方面的版本之间差异的概述。

 

图1:3DS v1.0(左)和3DS v2.0(右)中的典型交易。

 步骤1-3:开始交易并向发布者发送认证请求。步骤4-5:如果需要,客户由发行者认证。 步骤6:身份验证的结果通过客户(v1.0)或通过DS(v2.0)传达。步骤6-7:完成流程。 在此之后,遵循正常的支付流程(虚线)。

新组件3DS v2.0向3DS生态系统引入了新组件,以支持新的身份验证流程。商业服务器插件(MPI)由3DS服务器替代,并包含在“3DS请求方环境”中。 商户域中组件的集合术语包括3DS客户端,3DS请求器和3DS服务器。

•3DS客户端是与持卡人通信的组件。 这可以通过应用内(3DS SDK)和基于浏览器(3DS方法)完成。 两者都允许与3DS请求者(requestor)集成,以实现流畅的在线购物体验。

•3DS请求者(requestor)启动认证请求(AReq)消息,并且通过移动端应用程序/网站到的通道传递相关的数据到3DS服务器。

•3DS服务器,提供3DS请求器环境和DS之间的接口。

新流程

无摩擦的流程是3DS v1.0和3DSv2.0之间的根本区别之一。 在图1中,该流由绿色路径表示(步骤1-4)。 在该流程中,发卡行可以在ACS中执行的基于风险的认证来批准交易,从而避免和持卡人之间的互动与联络。

另一个差异可以以从发行行向商户交互的方式找到。 在3DS v1.0中,这是通过持卡人完成的,而在3DS v2.0中,通过DS进行通信的。 参看图1中的步骤6。以这种方式,可以经由单独的信道向商家通知认证结果,增强了安全性。

3DS v2.0还支持非付款客户认证。 该功能对于移动钱包的持卡人识别和验证(ID&V)和确保令牌请求的安全有着特别的作用。 非支付客户认证流程:在商户的网站上的购买期间执行类似于3DS v2.0认证流程,而其不包括特定的支付步骤(例如,支付开始,支付确认等)

新消息

阶段

3DS v1.0

3DS v2.0

预报

CRReq/CRRes

PReq/PRes

认真

PAReq/PARes

AReq/ARes

盘问

VEReq/VERes

CReq/CRes

结果

-

RReq/RRes

表1 :3DS交易的不同阶段在3DS v1.0和3DS v2.0之间的消息名称差异的概述。

版本2.0引入了组件之间交换的消息的新名称,如上表所示。 新消息类型是结果Result消息(结果请求和结果响应)。 该消息在发卡行(ACS系统)和商户(3DS服务器)之间交换,并且在客户验证之后传递结果。 与v1.0中的XML相比,v2.0消息在JSON中并且添加了新的数据元素以支持系统的新功能。

3DS V2.0的优势

3DS v2.0的引入具有几个优点,增强电子商务交易的安全性,同时优化持卡人的体验。商户将能够通过不同的渠道/设备使他们的结帐过程更平滑和可用,而不会危及安全。 3DS v2.0允许非付款验证流程,使商户可以提供额外的非付款安全服务。此外,3DS v2.0允许进一步开发基于风险的身份验证技术,用于持卡人身份的验证。基于自己的内部规则,发卡行将能够自主验证,例如授权小额交易,无需与持卡人进行额外的交互。

3DS可以在不同的终端而并不一定是商户的网站上认证客户将不仅增强用户体验,而且减少网络钓鱼和“中间人”攻击的机会。 此外,不依赖于静态密码将允许使用新的认证选项,例如通过外部生物特性(OOB)或一次性密码(OTP)进行认证。

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的实现可能对商户和发卡行都带来帮助。

作为结论,3DS v2.0倾向于解决3DSv1.0的多个技术痛点。 例如减少客户混淆,使得结账流程对于基于浏览器和应用内购买更平滑,引入无摩擦认证流,非支付认证流和增强的安全性。 然而,为了确保3DS v2.0的成功,发卡行和商家都需要积极参与到3DS v2.0中。 否则,3DS v2.0可能带来与3DS v1.0类似的技术和业务方面的挑战。

文:百科专栏作者:陈世文

了解更多金融行业相关信息,请关注微信公众号:支付百科

ID:PayPedia

财经自媒体联盟更多自媒体作者

新浪首页 语音播报 相关新闻 返回顶部