支付相关名称介绍
Webhook：
Webhook 是一个 API 概念，是微服务 API 的使用范式之一，也被成为反向 API，即前端不主动发送请求，完全由后端推送；简单来说，Webhook 就是一个接收 HTTP POST（或GET，PUT，DELETE）的URL，一个实现了 Webhook 的 API 提供商就是在当事件发生的时候会向这个配置好的 URL 发送一条信息，与请求-响应式不同，使用 Webhook 你可以实时接受到变化；
一般而言，WebHook旨在通过构建客户端对外API来接受数据，并处理收到的数据；服务端发送数据至客户端指定API中，完成整个回调（数据通知）过程；如微信收付款后，手机端会收到微信推送的消费信息等，这就是典型数据回调，当然这并不是简单的Webhook实现，其中包含消息的订阅与消费相关的技术知识，这里就不详细介绍了；
授权/Authorize：
通过收单行发送到发卡机构的消息，要求在付款人账户中预留资金以备以后过账。如果授权成功，将返回授权 ID 或代码作为收据。资金预留通常在有限时间段内有效，例如 7 天（一般收单行要求下游5-8天，卡组织要求收单行30天之内）；
交易授权： Authorize 操作验证付款人的卡详细信息，根据付款人的信用额度检查其是否有足够的资金，并尝试预留请求的资金。付款人的信用额度会减去授权金额的金额，资金将预留一段时间（多数情况为5-8 天），具体时间由卡组织和付款人的卡发行规则确定；
授权不会从付款人账户中收取资金，但会预留总订单金额，以备 Capture 操作从卡中收取资金并转账到您的账户。与“过账”交易相反，“授权”交易不会出现在付款人的账户账单中；
一般而言，授权交易使用场景多为酒店等，入住时需要提前授权酒店 1000 CNY 作为预付费金额，离店后确认消费（800 CNY）后，收单行会从 1000 CNY 中产生 800 CNY的收费，并将剩余的 200 CNY 授权金额解冻（自动撤销），还给持卡人，在 授权 1000 CNY 期间，这 1000 CNY 的金额不能用于其他消费；如果授权酒店 1000 CNY 作为预付费金额不足以满足消费，可以在授权有效期内进行授权更新，更新内容包括，授权金额（由 1000 更新为 1500）、授权时间（2023-05-05 更新为 2023-05-08）等；
授权撤销/void：
在收单行支持的情况下，网关可以为取消过账、部分过账或过期授权撤消未付授权金额。这可以帮助商户/支付公司遵守卡组织对于完全撤消和部分撤消的要求；
授权过期处理：
授权有效期过期后，网关将：
自动尝试取消授权并将资金退回付款人（如果收单行支持）。要实现此目的，您必须让 your payment service provider 在您的商家配置文件中启用“<自动撤消过期授权>”权限；
如果订单已经部分过账，并且您的收单行支持取消部分过账的授权，网关将尝试取消/撤消未付授权金额；
拒绝订单的任何 Capture 请求；
授权更新/Update Authorization：
网关允许您延长授权期间，以及有选择地增加或减少有效授权的授权金额（如果收单行支持）。为此，您必须让 your payment service provider 在您的商家配置文件中启用“更新授权”权限；
包括：
更新时间；延长日期；
更新金额 （剩余金额自动撤销）；
Capture：
为授权交易完成过账操作；资金从付款人账户转账到商家账户的转账流程。过账始终在系统的某个位置进行批处理，通过收单行主机，因此，在批处理结束、结算发生前资金不会真正转账。过账必须始终在授权之前执行，授权 ID 通过过账发送；
Capture 操作使用初始 Authorize 操作后获取的授权将资金从付款人账户转移到商户/支付机构的账户；过账通常由网关或通过收单行主机进行批处理，因此，在批处理结束、结算发生前资金不会实际转账；Capture 又称"Bill"、"Complete"；
Capture 应始终在成功授权之后执行，且至少必须通过 Capture 请求发送授权 ID；
过账金额时使用的货币必须与授权交易使用的货币匹配；
交易付款/Payment：
操作有效地将 Authorize 和 Capture 合并到一条消息内;一个交易会授权付款并将资金从付款人账户转移到商户/支付机构的账户；Pay 又称"Sale"、"Purchase"，不同机构、收单行、卡组织略有不同；
交易退款/Refund：
允许支付系统将现有订单的资金退还到付款人账户；仅当资金转账通过 Pay 或 Capture 完成时才能够执行退款；支付系统可以对原始交易执行任何数量的退款交易，但退款金额不能超过通过与订单相关的所有购买或过账交易获取的总额；执行退款可能出于很多原因，例如，不需要的商品、错误商品或次品退货等；
FTP：
FTP（File Transfer Protocol，文件传输协议） 是 TCP/IP 协议组中的协议之一。FTP协议包括两个组成部分，其一为FTP服务器，其二为FTP客户端。其中FTP服务器用来存储文件，用户可以使用FTP客户端通过FTP协议访问位于FTP服务器上的资源。在开发网站的时候，通常利用FTP协议把网页或程序传到Web服务器上。此外，由于FTP传输效率非常高，在网络上传输大的文件时，一般也采用该协议；
默认情况下FTP协议使用TCP端口中的 20和21这两个端口，其中20用于传输数据，21用于传输控制信息。但是，是否使用20作为传输数据的端口与FTP使用的传输模式有关，如果采用主动模式，那么数据传输端口就是20；如果采用被动模式，则具体最终使用哪个端口要服务器端和客户端协商决定；
SFTP：
在计算机领域，SSH文件传输协议（英语：SSH File Transfer Protocol，也称Secret FileTransfer Protocol，中文：安全文件传送协议，英文：Secure FTP或字母缩写：SFTP）是一数据流连接，提供文件访问、传输和管理功能的网络传输协议；SFTP可以为传输文件提供一种安全的网络的加密方法。SFTP 与 FTP 有着几乎一样的语法和功能。SFTP 为 SSH的其中一部分，是一种传输档案至 Blogger 伺服器的安全方式。其实在SSH软件包中，已经包含了一个叫作SFTP(Secure File Transfer Protocol)的安全文件信息传输子系统，SFTP本身没有单独的守护进程，它必须使用sshd守护进程(端口号默认是22)来完成相应的连接和答复操作，所以从某种意义上来说，SFTP并不像一个服务器程序，而更像是一个客户端程序。SFTP同样是使用加密传输认证信息和传输的数据，所以，使用SFTP是非常安全的。但是，由于这种传输方式使用了加密/解密技术，所以传输效率比普通的FTP要低得多；
FTP和SFTP在支付领域主要用于交易请款及清结算，一般而言使用SFTP会相对比较多，因为SFTP支持公私钥方式访问指定路径，使用SHH协议，安全性相对比较高，FTP虽然效率比较高一点，但是安全性相对较弱；
日切：
系统按照固定的时间段切分交易，系统从当前工作日切换到下一工作日；通俗的来说就是更换系统记账的时间；系统从当前工作日切换到下一工作日，日切过程中交易可以照常提交并正确处理返回；
同行交易（ON-US transaction）：
收单行和发卡行相同的交易（发卡行可以是收单行，但是收单行不一定是发卡行）；交易不必路由到网关去判断此卡的发卡银行；如中国银行的卡对另外一张中国银行的卡进行转账称之为：行内转账；
跨行交易（OFF-US transaction）：
收单行和发卡行不同的交易；交易必须路由到网关以判定此卡的发卡行；如中国银行的卡对平安银行的卡进行转账称之为：跨行转账；
3D安全（3DS，3D Secure）：
3D安全是由Visa（由Visa验证）和Mastercard（SecureCode）定义的一种协议；由发卡行提供访问控制服务器，通过PIN等附加身份验证因素对持卡人进行身份验证。目的是为了在网络交易时减少欺诈；3D指的是发卡行、收单行、卡组织；
访问控制服务器(ACS，Access Control Server)：
在发卡机构域内运行的组件，验证身份验证是否可用于卡号和设备类型，并对特定交易进行身份验证，如发卡行提供的服务， 按照3DS要求处理身份验证；
商家插件（MPI ，Merchant Plug-In)：
收单行的一个服务， 用来支持调用发卡行的3DS进行身份验证。它将卡信息通过注册验证请求（VEReq，Verifying Enrollment request ）发送到目录服务器（DS， directory server ）上。目录服务器DS 通过3D安全（3DS）来连接到访问控制器ACS以判断这个卡是否已经注册，将结果通过验证注册响应（VERes，Verifying Enrollment response ）返回。如果这个卡已经注册了， 那么在这个响应中将包含发卡行的访问控制器的URL，客户将被重定向到这个地址来执行验证；
银行识别号码（BIN ，Bank Identification Number)：
银行卡号的前4/6/8/9位，用于识别发卡行；
目录服务器（DS，Directory Server）：
这是支付网络托管的服务器，存储卡BIN到发卡行的映射；
支付开关（Payment Switch）：
此服务器与支付网关一起使用，它根据商户的规则来对交易做动态路由（切换），如成本、成功率或卡BIN等；
支付网关（Payment Gateway）：
支付网关连接在线商家和收单方来处理支付交易，它由银行或支付机构提供；
聚合支付（Payment Aggregator）：
聚合支付连接多个支付网关，并为在线商家提供多种支付选项；它对商家的好处是，通过集成，他们就可以获得多种支付选择。比如Ping++、Plural网关、PayU等；
验证注册请求（VEReq ，Verifying Enrollment Request)：
商家插件MPI发送给发卡行访问控制服务器ACS的请求，以检查该卡是否在3D安全系统上注册过；
验证注册响应（VERes ，Verifying Enrollment Response)：
从发卡行访问控制服务器ACS回复到商家插件MPI的响应，说明该卡是否注册了3DS；如果该卡注册了3DS，则它返回ACS的URL地址，客户将被重定向到这个地址来进行身份验证；
付款人认证请求（PAReq ，Payer Authentication Request)：
如果卡已经在3DS上注册，MPI会将浏览器重定向到ACS并发出付款人身份验证请求；
付款人认证响应（PARes，Payer Authentication Response)：
客户进行身份验证后，ACS返回付款人身份认证结果，表明验证是否成功；PARes被发送到商家插件MPI上， 其中包括本次交易信息，即本次支付是否是认证过的；
3DS认证（ Authentication）：
数字支付交易中的身份验证是为了验证持卡人是否是卡的所有者；3DS是一种验证持卡人身份的方法；
授权 （Authorisation） 和请款（ Capture）：
Authorization 和 Capture是一次支付行为的两个阶段；
Authorisation即授权，完成发卡行对持卡人支付能力的确认，即对支付人信息、卡是否有效以及账户余额是否充足的校验后，从持卡人的账户上对预授权金额进行冻结。信用卡不同于借记卡，消费的是信用额度，所以先进行冻结，后入账。信用卡有预冻结资金类目信息；
Capture请款是预授权后的动作， 将资金从客户账户实际转移到商户账户。Capture是对Authorization阶段冻结金额的落地，Authorization成功的资金只是冻结，或者把钱转移到发卡行的担保账户，Capture表示确认交易，将Authorization冻结的钱从用户账户扣除并转到商家账户；
预授权（Pre Authorisation）：
一般来说，授权和请款是连续动作；如果一个订单的履约需要比较长的时间，或者存在比较高的退款的风险， 如旅游、电商等场景， 请款会在授权完成后一个比较长的时间内执行的， 此时仅进行持卡人能力验证动作， 即预授权；
安全码：
一般印制在卡背后用来验证该卡的3-4位数字；
VISA卡的安全码是CVV2（Card Verification Value 2），有3位数字，平印在信用卡背面签名栏上卡号后4位处；
万事达卡（MarsterCard）的安全码是CVC2（Card Validation Code 2），有3位数字，平印在信用卡背面签名栏上卡号后4位处；
发现卡（Discover Card）的安全码是Cardmember ID，有3位数字，平印在信用卡背面签名栏上；
运通卡（American Express）的安全码是CID（Card Identification Number），有4位数字，平印在信用卡正面信用卡卡号上方；
银联卡（China Pay）的安全码叫做CVN2（Card Validation Number 2），有3位数字，平印在信用卡背面签名栏上卡号后4位处之后；
JCB卡（Japan Credit Bureau）的安全码叫做CAV2（ Card Authentication Value 2），有3位数字，平印在信用卡背面签名栏上卡号后4位处；
地址验证系统（AVS ，Address verification system)：
AVS是一个地址验证系统，是另一个安全层，持卡人的地址与发卡银行存档的地址相匹配。地址上存在的数字仅匹配，而不是完整的地址；
地址验证系统为支付交易提供另一层安全保障。交易中提供的持卡人的地址需要与发卡行中预留的地址相匹配（一般不需要完全一致）；
基点（Bps/bips ，Basis Points)：
Bips，也称为Bps，是指表示0.01个百分比（即0.0001）的基点。这通常用于指财务费用、利率等；
收单机构编码（ARN ，Acquirer reference number)：
用于识别资金在给定时间点从发卡行转移到商户账户的编码；
唯一交易编码（UTR，Unique Transaction Reference)：
UTR代表唯一的交易编码，它类似于ARN，但适用于UPI/NEFT/RTGS交易；
主账号（PAN ，Primary Account Number)：
PAN代表主账号，即信用卡/借记卡上的16位卡号；一般用于收单行和卡组织之间的标准称谓；
个人识别号码（PIN ，Personal Identification Number)：
PIN代表个人识别码，用于验证支付交易；
无效交易（Void transaction）和退款交易（Refund Transaction ）：
在结算前被取消的是无效交易；结算后取消的交易是退款交易；
3-D验证/3DS：
用于验证付款人身份的一种协议，最初由 Visa 开发，现在也被 Mastercard、JCB 和 American Express 所采用。使用 Directory Server 来确定付款人是否注册了 3DS，然后将付款人重定向到访问控制服务器 (ACS) 来进行身份验证。另请参见 Verified by Visa、SecureCode、J-Secure、SafeKey;
OTP：
一次性密码 One-Time Password，比如常见的手机短信验证码就是OTP，还有一些FTP等生成的code也算是OTP，目前跨境交易中最常见的就是手机短信验证码、邮件验证码；
OOB：
Out-of-Band，发生在挑战模式下，需要跳出商户或者收单页面去银行侧，如银行APP进行验证的模式，这个时候需要持卡人提供额外的风险验证信息，只有验证通过才能交易成功。如下为银联3DS的OOB模式在验证前的示例页面。顺便提一嘴，这个页面其实不是特别友善，因为这个按键“continue”是在跳转到发卡行APP验证完成之后才需要点击，如果放到这个页面就会导致误点击，可能会增加掉单率。看过Visa的这个OOB介绍目测最新版本的Visa 3DS规范已经要求做了优化；
主机捕获：
一种结算模式，收单行或处理器主机负责收集需要结算的交易，然后在批处理结束时进行结算。MasterCard Payment Gateway 或收单机构，卡组织将 Capture 和 Refund 交易（有可能是取消）发送到主机进行聚合。随后，MasterCard Payment Gateway 或主机结束批处理并结算交易；此类交易一般是D+1内处理；即将不同支付机构的交易根据标记划分，统一处理后，每日4-6次生成清结算/请款结果文件，并发送至支付机构指定服务器SFTP；
互操作域：
加快信息在发卡机构域和收单行域系统之间的传输，发卡机构、收单行 和 卡组之间的交互一般报文均为 ISO-8583 金融专属报文；金融数据交互需要用到加密机（硬件）；
交易：
表示商家发起的付款人账户和商家账户（反之亦然）之间的资金转账（或准备转账）请求；
交易 ID：
订单内交易的唯一识别码；一般由发起方（商户、收单机构）和接收方（收单机构、支付机构）自己生成；
付款人：
付款人具有发卡机构发放的支付工具（信用卡、移动设备），并使用此工具来从商家购买商品或服务；
付款会话：
付款会话或简单会话是参考会话的操作的所有请求字段和值的暂时容器。这样您可以在操作中使用会话来参考请求字段和值，而不是在操作请求中直接提供这些信息；一般用于页面交互、内嵌框架、session类API交互使用；
令牌：
日后可能用于参考卡详细信息来执行支付或授权的所存储卡详细信息的识别码；一般用于token支付，即绑卡支付使用；对应一整套的完整业务逻辑；
企业对企业（B2B）：
企业向其他企业出售商品使用的电子商务模式；B2B企业间最常用的就是公对公大额转账逻辑，此逻辑类似支付，但和支付存在较大差异；一般用于支付后的清结算后账单的代收、代付等；
企业对消费者（B2C）：
企业向各个购物者出售商品使用的电子商务模式；B2C最常用的就是建站平台或者购物平台，如淘宝、天猫、京东；
卡品牌（Card Brand）：
信用卡上的品牌名称，例如，Mastercard、Visa、Visa Debit。多数情况下，品牌名称与卡组织（请参见卡组织）名称相同，不过有些卡除外，如 Maestro（组织为 Mastercard）或自有品牌卡；目前已知全球最大的六大卡品牌/卡组分别为：银联国际、Visa Card、Master Card、Japan Credit Bureau、Diners Club、America Express；其中每个卡品牌还会推出不同的卡类型，如借记卡、信用卡、磁条卡、IC卡等；
1.借记卡:是基于银行卡中借记卡的支付工具；这种卡的特点是持卡人预先在发卡行存款。刷卡购物应以存款余额为限，一般不允许透支。如有急需，持卡人可允许短期小额商誉透支，并在规定期限内还本付息。目前国内所有银行发行的银行卡都属于借记卡；
2.信用卡:信用卡有广义和狭义之分。广义的信用卡是卡式支付工具的总称，狭义的信用卡是信用卡；
3.磁条卡：磁条卡是具有磁条编码或在卡的背面涂有一层磁性材料的卡片，或者在卡内放置磁带，磁性材料记录持卡人的姓名、号码等信息。持卡人使用磁条卡购物时，特约商户可以通过仪器读出信息，验证磁条卡及其持卡人的真伪，并启动相应的支付指令；
4.IC卡：IC卡是一种带有集成电路的卡；其中，只有存储器的IC卡称为存储卡；不仅具有存储器而且具有CPU处理功能的IC卡称为智能卡。由于其存储容量大、功能多、破译难度大、依赖模仿、组网要求低等特点，越来越受到社会各界的关注。它的功能非常丰富，可以作为信用卡、ATM卡等使用。，也可以是自带的“电子钱包”(现金)卡等。IC卡的具体功能包括:存取款、消费、转账、查询、修改密码、取现等；
幂等操作：
在产生相同结果时如果某个操作可以被重复调用，则该操作是幂等的。这意味着重复幂等操作始终是安全的。如果您未收到响应，是应重复发送请求。如果网关已经收到您的请求，其将返回初始响应；否则将处理该请求并返回响应；
强客户身份验证 (SCA)：
SCA 要求付款人在身份验证过程中提供以下三个因素中的两个：只有付款人知道的事，只有付款人才有的东西，付款人的身份标识。例如，可能要求付款人提供发卡机构发送到他们手机（付款人有的东西）上的一次性令牌和密码（付款人知道的事）；
支付服务提供商：
支付服务提供商又称 MSO（商家服务组织），是与商家有关系的支付网关上的一个实体，将商家登录到网关。您的支付服务提供商可能是您的收单行或第三方技术服务提供商；如中付就是一家支付技术服务商；
支付身份验证：
付款人在在线交易流程期间通过发卡银行验证其身份的流程。此流程通过每项交易请求的 Mastercard SecureCode™ 或 Verified by Visa™ 密码实现；类似于在自动柜员机上使用个人识别码 (PIN) 的概念；
收单行：
从商家获取交易的银行（通常）或其他付款处理系统。商家与收单行之间存在业务关系，通常在接收交易支付款项的收单行开设银行账户。MasterCard Payment Gateway 可以将交易发送到收单行运行的主机或交换机。另请参见收单行链接；
收单行链接：
又称商家收单行链接或商家收单行关系。此配置允许商家通过指定收单行处理交易。每个商家至少有一个收单行链接，部分商家有多个链接 - 这种情况下，将使用卡品牌和货币来确定哪个收单行链接应处理每笔交易。每个链接有一个或多个分配的终端；部分支付机构称之为终端号，即通过不同的终端号，蒋交易划分至不同的区块进行处理；
无卡交易：
付款人和/或支付工具未实际出现在商家位置的交易。支付工具详细信息由付款人通过互联网、电话或邮件提供；无卡交易一般用于线上支付、网页、手机端支付；卡交易一般包括无卡交易和有卡交易，有卡交易一般用于ATM、POS机交易等；
资金流：
什么是信息流和资金流？就如同一条小溪从高到低进行流动，“流”就是有规律的流动；
信息流就是信息的流动，这里的信息可以理解为支付指令所承载的信息，而流动就是支付指令在不同支付参与者或者支付系统之间的传递的过程，例如你在京东用微信支付了100元，那么支付信息流就从京东传递到了微信，如果你在微信支付时用了微信中的银行卡快捷支付，那么中间又涉及到了跨银行和微信支付之间的信息流动，断了直联之后清算机构参与了进来，这种情况下支付信息就从京东到了微信，从微信到了网联，从网联到了银行卡开户行。所以，不同的支付场景、支付工具、支付类型会形成不同的支付信息传递链路，也就形成了不同的支付信息流；
资金流就是资金的流动，我们知道支付的本质是货币的转移，无论是现金转移还是不同的电子货币在不同账户之间的转移。所以，资金流就是货币在支付活动中不同参与者之间的流动；
信息流和资金流不是孤立存在的，而是相互依存，资金的流动依赖信息流动，以信息流为依据；同样资金流动也是信息流动的必然结果，发生信息流动的目的就是推动资金的转移以完成最终的支付；
终端：
表示 POS 终端的虚拟版本。卡组织或收单行在将交易发送到收单行时始终表示交易来自终端；
终端过账：
一种结算模式，终端负责掌管流程以对需要结算的交易执行过账和退款，然后在批处理结束时作为结算批次将全部交易发送到主机。美国的多数收单行使用终端过账，因此由 部分卡组 负责代表商家聚合交易，然后在批处理结束一段时间后通过主机结算这些交易；
结算批次：
结算批次指按收单行/处理器将交易分组到付款组。部分处理器在规定时间停止每天的处理，并为第二天的交易开始新的批处理应该注意的是，批处理的开始时间（日切）可能与商家的营业时间不同；
邮购订单电话订单：
表示邮购订单/电话订单，是商家通过邮购或电话获取的传统无卡订单的通用术语。MOTO 还是使用 Merchant Administration 执行的初始交易（Authorization 或 Pay）的传统名称；如商户系统收银台；
Directory Server：
在互操作域运行的服务器硬件/软件实体；其维护可使用身份验证的卡范围列表，并协调商家服务器插件与访问控制服务器之间的通信，以确定是否可对某个卡号和设备类型使用身份验证；
Void：
取消交易的付款部分，以不在付款人和商家之间转移资金。交易被取消且不在付款人账单中记录交易信息。取消只能对在一天结束时尚未发送到银行进行处理的交易执行（另请参见结算批次）。如果交易已由 MasterCard Payment Gateway 发送到商家银行进行处理，那么商家必须执行退款而不是取消；
风控相关解析：
风控起源：
风控即风险控制；“风险”一词的由来已久，最为普遍的一种说法是，远古时期渔民每次出海前，都要祈祷风平浪静、满载而归；在长期的捕捞实践中，渔民深深地体会到，“风”给他们带来的的危险。“风”即意味着“险”，因此有了“风险”一词；风险控制，顾名思义，主要是通过一系列管理措施，把可避免的危害最小化，防止在风险发生时造成不必要的损失；在支付体系中旨在通过一系列事前、事中、事后的风控措施确保从商户开户、交易、到最后的打款过程中防止各类风险，以避免造成损失；
第三方支付风控系统不同于其他金融机构的风控业务系统，第三方支付风控系统除了要关注自身的业务风险之外还要时刻关心央妈的合规风险，以便更好地把握全面风险控制；
一般对于第三方支付风控系统而言，事前风控处理主要依托外部联防系统如KYC系统、制裁名单系统等，主要依靠银联、清算协会等国家机构；
事前风控处理（进件行为）
1）小微商户管理
根据商户进件查询商户个人/法人信息是否虚假，可联防银联风控系统查询是否有个人欺诈风险（虚假申请人员，经济犯罪人员，失信人员名单、制裁公司、法人信息等）、个人合规风险（疑似赌客标签，营销套利标签，账户风险标签节点，II/III类账户风险标签等）、黑名单等；
2）企业商户管理
根据商户进件查询商户信息，可联防银联风控系统查询是否禁止发展商户、收单机构报送的风险商户、银联高风险商户、疑似涉赌商户、高法失信企业、工商经营异常名录、工商严重违法失信企业、商户频繁变更信息节点等；
事中风控处理（交易行为）
事中风控主要体现在交易行为，为此我们可以建立一套交易规则匹配，当发生交易时，会通过规则引擎来过滤掉命中的交易记录；
1）实时刷卡交易/扫码规则
当日单笔、累积上限、频繁交易、多失败、黑名单异常、交易金额/时间异常（交易金额位数88,66,99等，时间常发生在凌晨或其它异常时间）等；诸如系统内风控、外风控等相关风控控规则；
2）银行卡支付/互联网支付监控规则
当日多笔交易相同金额（规律尾数00-99或68/69/89/98/998或含999）等），某个时间段内交易金额大于设定的金额，客户收款人年龄，黑名单，频繁交易等；
3）反洗钱规则
特殊金额尾数、交易IP与装机IP不一致、定位异常、新商户交易频率高、单笔整数、大额交易频繁等；
4）实时交易定位匹配规则
特定不允许交易地区、短时间内交易地址不一致、虚拟IP地址等；
5）风险阻断/资金拦截
事中风控在支付流程中主要依靠支付机构本身的风控规则（内风控及自定义内风控规则）、三方风控机构的风控体系（CyberSource、MaxMind）等，在整个支付体系中，事中风控是支付公司最需要重点关注的节点，因为这个节点直接影响当前交易的处理方式（拒绝、上送渠道方），当交易量足够大的时候，强烈建议支付公司搭建自己的风控体系，随着大数据的普及，持卡人客户画像，预判持卡人交易行为是否是本人的行为已经逐渐成为行业的主流，如 3DS 2.3 推出的指纹认证，面部识别等方式也正在普及；
事后风控处理
1）接入联防银联风控系统，清算协会风控系统等，同步商户数据；
2）针对高异常的商户资金延迟结算；
3）商户回检/回访；
4）建立商户风险评分/等级，资金管控等；
5）三方数据预警；如Verify、Ethoca、RDR等相关拒付预警数据及其处理逻辑；
2、3DS相关业务介绍：
前言：全球主流卡组已经在2022年10月全部停止对3DS1.0的认证服务，开始支持3DS2.0认证；
3DS相关的背景知识
在介绍3DS之前，为方便大家理解，先给大家铺垫一些相关的背景知识；
1.EMVCo
EMVCo成立于1999年，中文全名叫国际芯片卡及支付技术标准组织，EMV三个字母分别是Europay、Mastercard、Visa，是EMV组织1999年最初成立时的三家公司，不过，2002年，万事达收购Europay；
后来，另外四家卡组织：JCB、美国运通（AE）、中国银联以及Discover分别陆续于2004年、2009年、2013年加入，所以目前EMVCo的组成成员为这全球6大主流卡组：Mastercard、Visa、JCB、美国运通、中国银联以及Discover。
EMVCo成立之初，是为了统一接触式卡在全球的标准，后来随着全球的移动通信技术、智能手机的不断发展，EMVCo目前制定的支付技术标准已涵盖接触式、非接、移动支付、支付标记化、QRC、SRC以及本文的3DS等产品和业务。官网：https://www.emvco.com/；
3DS对应官网规范文档：https://www.emvco.com/specifications/?tax%5Bspecifications_categories%5D%5B32%5D%5B%5D=84
3DS知识库：https://www.emvco.com/knowledge-hub/?tax%5Bknowledge-hub_categories%5D%5B%5D=163
2.CNP
Card Not Present，即无卡交易，也称非面对面交易或者信用卡无卡支付交易，指的是持卡人只需要输入卡信息，如卡号、有效期及CVN等有效信息，不用刷卡、无需当面交易即可完成付款的过程。CNP交易虽然给支付带来了便利，但是一旦持卡人的卡信息保存不当或者被钓鱼等导致卡信息泄露，就有可能被盗卡者直接拿来支付，给持卡人和商户等带来损失；
根据Nilson的报告和Ingenico的数据显示，2016年美国超过50%的欺诈损失与CNP交易的欺诈密切相关，这一比率甚至超过了银行卡造假欺诈。而在欧洲，CNP交易的欺诈率约是店内交易店内支付交易的20倍。预计到2025年，全球银行卡欺诈损失可能将高达437.8亿美元；而3DS可以让消费者在进行CNP无卡交易中进行身份认证，这能大大降低交易的欺诈风险；
3.PSD和SCA
英文全称是Payment Services Directive，即欧盟（EU）的《支付服务修订法案》。PSD第一版在2007年发布，第二版也就是PSD2是在2016年1月开始生效，欧盟成员国需要在2018年1月之前将PSD2转化成国内法；
制定PSD的初衷是使欧洲支付委员会（EPC） 75 个成员国之间付款更便捷，并改善对欧盟成员国消费者的保护。PSD 的首要目标是通过将支付服务提供商集合在一套法规和标准之下，加强欧洲支付行业的参与和竞争。它适用于银行、金融机构以及非金融科技企业等；PSD主要面向于支付领域，重点是数据的共享；
PSD2与PSD的最大更新主要有三点：
一是将第三方服务商（如新型的支付科技公司等）纳入监管范围，覆盖范围的扩大有助于监管机构进一步保护消费者权益，同时有利于规范化行业的发展，防止劣币驱逐良币；
二是要求银行向第三方服务商开放以前被银行垄断的数据，包括账户信息数据和账户交易数据，通过数据开放及共享，有助于推动欧洲传统银行和金融科技企业更深层次地协作和竞争，最终使消费者利益进一步最大化；
三是强制实行线上支付认证（SCA），PSD2对欧洲各大银行及支付公司强制实行线上付款认证体系，主要是为了强化对于消费者线上消费的保护，阻止交易欺诈；
SCA英文全称为Strong Customer Authentication，即强用户身份认证，是属于PSD2中其中的一项要求，要求用户在支付的时候必须完成至少双因素认证，包括密码、OTP、人脸识别等；
4.GDPR
英文全称是General Data Protection Regulation，即欧洲的通用数据保护条例，该条例于2016年4月由欧洲议会和理事会通过，并于2018年5月生效。GDPR旨在统一各欧盟成员国的数据保护立法，加大数据保护力度，以顺应大数据时代下对隐私和个人信息保护的需求；虽然看似仅影响到在欧洲的机构，实际上目前该条例的应用范围已经逐步扩大，即使一个主体不属于欧盟成员国的机构，只要满足以下两个条件之一，在任何收集、传输、保留或处理涉及到欧盟成员国的个人信息的机构都收到该条例管控；
（1）为了向欧盟境内可识别的自然人提供商品和服务而收集、处理他们的信息。比如法国巴黎的姆巴佩通过入驻在敦煌网的沈阳乐乐鸭架出口商户进货一批一口香鸭架，乐乐鸭架在收集或者处理姆巴佩的个人数据时，就要受到GDPR的约束；
（2）任何网站甚至手机软件（APP）只要能够被欧盟境内的个人所访问和使用，产品或服务使用的语言是英语或者特定的欧盟成员国语言、产品标识的价格为欧元，都可以被理解为该产品、服务的目标用户包括欧盟境内用户，从而需要适用GDPR；
GDPR的处罚力度惊人，根据GDPR，欧盟数据保护机构可以对不合规的公司处以最高2000万欧元或上一财年全球营业额4%的罚款，以高者为准；
5.EEA
EEA全称为European Economic Area，中文名可以翻译为欧洲经济区，目前包括30个成员国家，其中27个来自欧盟（EU），3个来自欧洲自由贸易联盟（EFTA）；
27个欧盟（EU）国家为：Austria、Belgium、Bulgaria、Croatia、Cyprus、Czech Republic、Denmark、Estonia、Finland、France、Germany、Greece、Hungary、Ireland、Italy、Latvia、Lithuania、Luxembourg、Malta、The Netherlands、Poland、Portugal、Romania、Slovakia、Slovenia、Spain、Sweden；
3个欧洲自由贸易联盟（EFTA）国家为：Iceland、Liechtenstein、Norway，顺便提一下，EFTA国家一共有4个，剩余那个是Switzerland，据说因为公投，居民反对加入EEA。而另一个著名的欧洲国家英国，由于脱欧，目前也已经不属于EEA的成员国；
EEA是目前全球最大的自由贸易区，成立EEA的目的是通过消除贸易壁垒和实行平等的竞争条件和遵守同样的规则来加强成员国之间的贸易和经济关系。通俗的来说，就是EEA成员国内的，可以享受更低的关税、更便利的审批手续等，就类似我们和东盟签订的RECP一样，入群了，就能享受到经贸方面的各种便利化措施；
这里为啥要特别提一下EEA呢？
因为：PSD2已逐步被要求加入欧洲经济区（EEA）各个成员国的法律法规中，而实施的最终期限被要求设定为2018年1月13日，虽然各个成员遵循的日期不同，但未来PSD2肯定会最终在EEA成员国落地，而3DS 2.0作为PSD2中的一项重要方案，EEA的成员国同样需要通过本国的法律法规来落实执行，所以如果有涉及到3DS相关业务的同学需要清楚的了解EEA，知道3DS实施的范围；
什么是3DS：
3D-secure，全称是3-Domain Secure，3DS是一种针对在线支付交易场景的身份验证协议，或者说是一种身份验证解决方案，这里的3D就是包括Acquirer Domain, Interoperability Domain 和 Issuer Domain，翻译成中文就是包括三个域，分别是收单域、交互域（在四方模式下，通常为卡组，所以也可以叫卡组域）、发卡域，支付交易的数据通过在这三个域的传输及验证，可以尽可能的保证交易的真实性，降低交易的欺诈可能性，所以3DS认证目的就是通过多重认证，比如OTP（2.3）、指纹（2.2）、人脸（2.2）等来提高支付的安全系数，从而降低交易的欺诈率；
从上面的解释可以看出，3DS符合PSD2中SCA的要求，而根据PSD2的要求，只要交易受PSD2监管的商户必须在2019年9月14日前支持3DS 2.0版本以上认证方式，实际上，不管是3DS1.0还是3DS2.0，其实都是符合SCA的多要素验证要求的；
3DS的各个版本：
从1999年3DS1.0开始推出以来，3DS已经经历了两个大版本：3DS1.0和3DS2.X，其中3DS2.X又分为3DS2.1、3DS2.2、3DS2.3。3DS1.0并不是EMVCo标准，而是Visa在2003年首先推出，然后MasterCard等卡组也逐步推出类似的方案，推出3DS1.0的卡组都是独自的维护对应的规范，并不是统一的规范，银联没有3DS1.0产品，但是实际上提供了类似的产品叫Secure-Plus，用户体验同3DS1.0基本保持一致。从3DS2.1开始，才是EMVCo统一的规范标准方案，从这个版本开始银联也推出了相应的方案；
从下表大家可以看出各个版本的异同：
从上表可以看出：
1. 3DS1.0主要的缺点
只支持PC浏览器，不支持APP和WAP，这个也是由于1.0版本推出较早导致；
只支持静态密码和OTP验证，并且必须跳到银行的页面去完成验证，用户体验非常差，并且弹出窗口也会增加网络钓鱼和被攻击的风险；
由于OTP常常收不到以及跳转不成功等问题，导致3DS1.0的商户掉单率非常高；
所以，3DS1.0版本已经无法适应移动互联网时代的发展，这也是卡组即将要放弃1.0版本的原因。而3DS2.X支持WEB、WAP、APP多终端，验证方式更加多样化，且无需跳转验证，用户体验、支付成功率等都得到了极大的改善；
2. 3DS2.1版本的优化点
在看到了3DS1.0的缺点之后，为了顺应时代的发展，6大卡组最终推出了统一规范的3DS2.1版本。其主要的优化点从上表也可以看出：
统一了技术标准和规范；
支持除PC浏览器之外的WAP浏览器和APP；
除了挑战模式外，增加了平滑模式，即无需跳转无需额外认证即可快速完成支付；
认证方式除了静态密码和OTP外，新增了生物验证，如指纹、人脸识别等，提高了用户体验；
除了支持支付交易的认证外，也支持单纯的非支付认证交易；
3. 3DS2.2版本的优化点
支持商户或者支付服务商通过应用交易风险分析系统（TRA）向发卡行请求低风险豁免，TRA允许商户或支付服务商在欺诈率低于特定阈值的情况下直接让交易避开SCA校验，在2.1版本中已有部分发卡行支持这一功能，2.2版本要求全部发卡行都必须支持；
支持委托认证，也就是支持获得相关资质的第三方机构（如TPSP或者收单机构）代替发卡行进行身份认证，在交易的时候，发卡行无需重复验证，仅需三方机构告知其该笔交易已经验证通过即可，可以降低掉单率；
还支持离线认证或者叫解耦认证，也就是持卡人可以在不同于下单的其他设备终端完成身份认证，比如在浏览器下单，在手机APP完成认证，只要间隔的时间没有超出商户设置的时间即可；
支持3RI功能，即在一次交易的成功身份认证之后，商户可以获得该笔交易对应的密钥，然后可以多次使用该密钥对该笔交易进行多次授权而不需要重复的发起身份认证，大大提升了持卡人的支付体验，有点类似之前文章介绍的多笔请款场景，或者跟recurring交易类似；
4. 3DS2.3版本的优化点
在用户体验方面：主要是新增了设备白名单，允许持卡人将信任的设备加入白名单，请求银行后续对同一设备发起的交易采用平滑模式，另外，还对OOB功能进行了优化，当持卡人进行了预先设置之后，支持在交易的时候，如果需要离开商户的APP到银行的APP去做身份认证，银行APP会自动弹出该笔交易对应的提醒页面，持卡人直接点击该页面即可快速完成验证，这个可以大大简化和加快持卡人的支付流程；
在数据方面：2.3版本涵盖了更多的数据，包括交易、支付方式以及设备的数据，如Recurring交易和EMV Payment Token的数据也会同样被采集发送发卡行，可以让发卡行等更快的完成交易的验证，为持卡人身份验证更快、更简单；
在实施应用3DS方面：2.3版本通过新增支持OS/平台提供商并新增了分离式SDK（Split-SDK）规范，进一步拓展了3DS的应用范围，除了传统的Ecommerce外，还包括旅游、视频和游戏行业等；
增提高交易安全和降低欺诈方面： 2.3版本除了继续根据PSD2的强客户身份验证(SCA)要求进行双因素认证外，EMVCo还通过与万维网联盟(W3C)和FIDO联盟合作，2.3版本支持Web认证和SPC安全支付认证的，发行商和商家可以在EMV 3DS交易流程中使用这些认证来提高交易的安全性，降低欺诈风险；
3DS属于卡基交易场景的产物，卡基预计在未来短期内仍会持续的发展，特别是境外市场，但是在国内，已逐步从卡基往账基方向发展，所以，基于卡基的3DS注定未来仍将主要在境外市场，特别是EEA这些实施了PSD2法案的国家，国内大概率不会全面铺开；
用户体验：
先用几个3DS的用户体验流程页面截图给大家有视觉上的认识；
（一）3DS1.0
关于1.0这个版本，仅给大家展示用户体验流程，重点介绍2.0版本；
下图为1.0版本通过使用卡组Visa验证密码的用户体验页面：
从用户体验的流程图，大家也可以看出1.0版本的主要缺陷：每笔交易验证都必须进行页面的跳转（跳转卡组织或者发卡行等进行验证，完成交易再返回商户或者收单页面。部分浏览器需要设置允许弹窗，所以第2步为Conditional）、验证方式仅支持静态密码和OTP等；
（二）3DS2.X
2.0版本的用户体验，一般分为平滑模式/无障碍流（ Frictionless Flow）和挑战模式（ Challenge Flow）两种，前者的意思就是用户在做风险验证的时候基本无感，如丝般顺滑，一般发生在该笔交易被交易各方认为风险比较低的情况下，而后者，用户需要进行额外的身份验证，比如OTP、生物认证（如指纹、人脸识别等），这种情况一般发生在现有数据无法识别该笔交易可控情况下；
大家可以看以下两图：
1. 平滑模式
2. 挑战模式
（1）OTP验证方式
（2）指纹验证方式
从上面1.0和2.0的版本的用户体验流程也可以看出，在验证前，用户都必须先输入卡信息或者选择前期已绑定支付账户的对应支付卡等。
另外，根据Visa的统计数据，在电商交易中，有高达95%的交易为平滑模式，意思是仅有5%的交易需要进行额外的身份认证，而3DS2.0版本相比1.0版本，掉单率下降70%，客户交易时间降低了85%。这说明新版本的3DS，不仅大大提高了客户的支付体验，还增加了商户的成功交易，从而提高了商户接入的意愿；
域和组件：
之前也提到，3DS交易中会涉及到三大域，分别是收单域、交互域、发卡域，阿xiong根据EMV规范自己进行了翻译并画了个图，具体如下：
基于EMVCo的规范《EMVCo_3DS_CoreSpec_v2.3_20213009》简单介绍以下三个域：
（一）收单域
跟其他传统的非3DS交易一样，这个域最核心的作用就是服务持卡人、收集数据及发起交易等，在一笔3DS交易中包含3DS请求环境（3DS Requestor Environment）、3DS集成器（3DS Integrator）和收单机构（Acquirer）三部分：
1. 3DS请求环境
这个是用中文直译的，有点拗口，简单来说也就是3DS交易请求的所有相关发起方，或者发起模块，请求环境也包括三部分3DS请求方（3DS Requestor）、3DS客户端（3DS Client）、3DS服务器（3DS Server）：
（1）3DS请求方
3DS Requestor是3DS认证交易的发起方并从用户的设备获取交易所需要的数据，这个角色可以由商户，也可以由钱包等来扮演。在支付认证中，3DS Requestor通常代表在线购物的对应商户的web服务器；
3DS Requestor通常通过用户设备中的购物APP或者3DS Method（下文会介绍）或者浏览器与3DS客户端（3DS Client，下文会介绍）进行交互，上图中也标注了；
而从介质角度来说，3DS请求方支持APP、浏览器（包括WEB浏览器和WAP浏览器），不同的介质作为发起方，EMVCo提供了不同的标准化接入方式及规范；
基于APP
EMV提供了标准的3DS SDK，商户或者收单或者钱包等，可以预先将该SDK嵌入提供给用户使用的APP，这个APP 在3DS交易中也成为3DS Requestor App，比如如果云闪付APP海外版本支持发起3DS交易，其也可以称为是3DS Requestor App。通过嵌入的3DS SDK，在3DS交易中，可以唤起相应的用户界面，为用户提供安全认证等服务；
基于浏览器
这里要介绍下EMV提供的一个脚本，叫3DS Method，它是预置于 3DS 请求方例如商户购物网站的标准脚本，可以为3DS请求方获取浏览器和设备的数据供后续3DS交易进行风险认证；
（2）3DS客户端
3DS客户端即3DS Client，是用户设备上启动3DS认证交易的组件，在一笔3DS认证交易中，3DS客户端与3DS请求方进行后台交互，从而发起交易；
3DS Client一般可以应用于以下两种模式：
基于APP
此时3DS Client以SDK的形式嵌入在3DS Requestor App中，并服务于用户。
基于浏览器
此时3DS Client以3DS Method的形式嵌入在3DS Requestor’s如商户的网站，在3DS交易的时候随时调用；大部分卡组客户端或者说客户设备都是仅支持浏览器或APP，有的卡组如Visa还可以支持游戏操控器，可以打游戏图中快速进行付款；
（3）3DS服务器
3DS服务器即3DS Server，它主要作用是收集交易所必要的信息，协助3DS 请求环境和目录服务器（DS，下文会介绍）进行信息交互。同时还能保证传输信息的安全。例如用户设备的数据在3DS客户端获取后将传输到3DS服务器，并由3DS服务器将数据上送至DS；另外，在授权交易中，3DS服务器同样起着承上启下的作用，将会通过它调收单机构系统，发起商户侧的授权请求；
商户或者收单机构，可以通过自建或者代建两种方式实施3DS Server，自建即商户或收单自己开发或者采购3DS Server软件，然后自己进行维护，而代建就是直接使用第三方的3DS Server软件，由第三方进行3DS Server的运维。符合EMV标准的服务商列表可以见EMVCo的服务商列表（https://www.emvco.com/approved-registered/service-providers/）；
2. 3DS集成器
3DS集成器即3DS Integrator，3DS Integrator的角色是提供3DS服务器和3DS客户端，即3DS集成器包含了3DS服务器和3DS客户端，商户只要在APP或者官网等集成了3DS Integrator即可在商户端支持3DS交易。
3. 收单机构
收单机构在3DS支付交易中，主要有两方面的作用，其实和传统交易差别不大。
一个是业务层面，实现与商户的收单合作签署收单协议，为商户实现3DS提供支持，另一个是系统层面，为其收单的商户提供授权支持，包括联机交易和资金清算等。
后面的系统交互流程大家也可以看到具体收单机构扮演的角色和承担的作用；
（二）交互域
在3DS四方模式中，这个域主要由卡组织承担，核心作用是交易的转接及代理认证等。
根据EMVCo的规范，该域主要包含目录服务器Directory Server (DS)、目录服务器证书颁发机构Directory Server Certificate Authority (DS CA)、授权系统Authorisation System三部分。
1. 目录服务器（DS）：
根据规范，通过阿xiong仅有的翻译能力及理解力，DS的作用主要包括如下6点：
验证3DS服务器和ACS：也就是验证3DS服务器上送和ACS回传的信息，降低交易的风险。
在3DS服务器和ACS之间路由消息：由于DS是属于卡组域，这个就跟卡组的其他系统一样，进行交易信息的转接或者说路由，保证交易信息的上传下达。
验证3DS服务器、3DS SDK和3DS Requestor：验证这三者上送的交易信息，从而保证交易的真实，降低风险。
定义特定的规则(例如：标识、超时域值等）：这个也是卡组的常规工作，就是标准化3DS交易中的一些规则，比如标识的使用、time-out值的设置要求以及如银联中关于BIN表的配置等。
为3DS服务器和ACS提供接入服务：为两者提供接入的标准化接口，可以根据该接口实现3DS交易认证功能。
维护ACS和DS协议版本列表和3DS Method的URL：我理解应该是DS需要对通过提前的手动配置或者交易时上送的协议版本或者URL进行存储或者维护，供各方随时调用。
2. 目录服务器证书颁发机构：
直接根据规范翻译：DS CA作用主要是为3DS SDK生成DS公钥，并为可供3DS认证组件使用的TLS证书。一般来说，DS CA通常是由负责特定DS的支付系统来运行；很明显，其实从名字也可以看出，作用就是生成3DS认证相关的证书秘钥等，保证交易的合法安全的传输；
3. 授权系统：
这个组件就比较好理解了， 就是在3DS支付交易场景，认证成功后的卡组授权系统，主要就是负责在受理侧和发卡侧之间进行授权交易的转接。这也是卡组在四方模式中的核心功能，准确的说就是联机交易数据的转接以及出具清算报告并支持资金的结算等。对于银联来说一般就是CUPS（UTMS）或者GSCS（国业）；
（三）发卡域
发卡域主要包含四个组件（其实一直觉得翻译成模块更合适，但是很多翻译都是组件，也就随大流了），分别是持卡人（Cardholder）、客户设备（Consumer Device）、发卡机构（Issuer）、访问控制服务器（Access Control Server (ACS)）。
1. 持卡人
这个就比较好理解了，就是拥有这个银行卡的人，或者说电商平台的客户。在一笔3DS交易中，就是授权并操作提供各种认证数据的授权方，特别在挑战模式下的交易，需要进行OTP、指纹或者人脸识别等操作；
2. 客户设备
客户购物所持的设备，比如手机或者电脑，该设备必须可以运行3DS Requestor App或者支持在浏览器上显示可用于3DS认证的网站；
3DS的一笔交易的发起，可以是基于APP、浏览器或者3RI（3DS-Requestor-initiated），这里简单介绍下3RI，3RI对应的3DS交易是从商户来发起，一般发生在该持卡人的账户信息已经上送过，商户通过发起认证交易来确认该持卡人的付款方式还有效。类似的场景可以参考在线订购，比如订购流媒体服务等；
3. 发卡机构
和传统标准的四方模式交易承担的角色差不多，发卡机构这里主要承担以下几个作用：
向持卡人发行支持支付交易的银行卡；
确定可以支持3DS交易的卡BIN，也就是BIN表；
将BIN表同步给卡组织，维护到对应的DS中，供交易的时候进行调用；
4. 访问控制服务器（ACS）
ACS配置了3DS交易的认证规则，由发卡机构进行运维使用。其作用包括以下几点：
确定某个卡号是否支持3DS交易：如果卡BIN提前给了卡组维护到DS，理论上这个认证一般已经前置到了卡组
确定一台用户的设备是否能用于3DS认证交易：这里的判断逻辑应该是根据客户的手机上是否有3DS Requestor APP或者浏览器是否支持3DS Method
认证持卡人信息或者账户信息，确认交易的安全性
三、系统交互流程
虽然标准规范都是EMVCo出的，但是每个卡组其实会有些差异，下面主要以全球发卡量最大的卡组银联的3DS为例，介绍3DS的交易流程；一笔银联的3DS支付交易流程一般分为三个子流程：准备流程、认证流程和授权流程；
以下是基于APP端的完整的交互流程：
以下是支付系统使用的完整交互流程（我们自己的）：
（一）名词解释
在介绍各个流程前，先给大家补充一些名词解释，包括AV值、ECI、OTP、OOB等；
AV值：身份验证值 Authentication Value（AV），由 ACS 生成的加密值，在授权处理过程中为授权系统提供验证身份验证结果的完整性提供一种方法。AV 算法由各支付系统定义。
ECI：电子商务标识 Electronic Commerce Indicator，也是由ACS 生成的，特定于支付系统的值，用于指示持卡人身份验证的结果。另外，银联另外还有通过ECI来区分认证类产品和非认证类产品，09为认证类产品，就是交易的适合需要通过发卡行或者银联代理认证的产品，而10为非认证产品，即无需发卡行或者银联认证的产品。
身份验证标识符：由卡组织的 DS 提供给 3DS Requestor 和 ACS，用来唯一标识 DS 系统内的身份验证交易。商户/收单行在授权报文中将该ID 作为身份验证标识符，而发卡机构应使用该身份验证标识符来验证 AV 值。
OTP：一次性密码 One-Time Password，比如常见的手机短信验证码就是OTP，还有一些FTP等生成的code也算是OTP，目前跨境交易中最常见的就是手机短信验证码、邮件验证码；
OOB：Out-of-Band，发生在挑战模式下，需要跳出商户或者收单页面去银行侧，如银行APP进行验证的模式，这个时候需要持卡人提供额外的风险验证信息，只有验证通过才能交易成功。如下为银联3DS的OOB模式在验证前的示例页面。顺便提一嘴，这个页面其实不是特别友善，因为这个按键“continue”是在跳转到发卡行APP验证完成之后才需要点击，如果放到这个页面就会导致误点击，可能会增加掉单率。看过Visa的这个OOB介绍目测最新版本的Visa 3DS规范已经要求做了优化；
（二）流程说明
1. 准备流程
准备流程的目的是为了获取3DS交易支持的最新卡BIN列表，从而在交易中确认哪些卡支持3DS交易，一般准备交易可以通过系统定时跑批来实现，比如一天系统跑一个任务；对于银联3DS，就是3DS客户端调银联的DS接口来实现；
2. 认证流程
认证交易，前面也提到了，有平滑模式和挑战模式。当发卡行的ACS进行风险认证时，可以根据商户的要求（这种情况一般发生在商户觉得交易可能有一定欺诈风险，想通过3DS验证来确定客户是不是真正的持卡人，如果3DS验证成功了，风险责任就可以转移到发卡行了）、发卡行要求或者其他风险因素确认是否使用挑战模式；
另外，针对在认证过程中，如果发卡行的ACS临时无法对持卡人进行身份验证时，银联还会提供尝试验证服务，也就是通过银联的DS系统将身份验证请求路由到银联尝试验证服务器来代理发卡行的ACS来进行认证，从风险角度来说，同样属于发卡侧承担风险；
如下为尝试验证系统交互流程：
在认证交易中，发卡行的ACS会通过不同的值来代替不同的认证结果，也就是交易状态，具体如下表所示：
3. 授权流程
在完成了认证之后，商户可以通过收单向卡组发起授权交易请求；
四、风险责任转移
这点非常重要，其实也是很多商户愿意改造去支持3DS的最重要原因之一；
根据EMVCo六大卡组统一行程的规范约定，一笔成功的3DS支付交易，如果出现了欺诈风险，责任将转移到发卡行，也就是说，受理侧，包括商户和收单都不用承担责任。当然，这笔成功的3DS支付交易需满足如下两个条件：
1. ECI值必须得有，且必须是05或者06，也就是如上文提到的，这笔交易必须经发卡行或者卡组织验证通过；
2. 受理侧上送的报文必须包含有效且已经被验证过的AV值：如何验证？前文其实提到了身份验证标识符（Authentication ID），发卡就是用这个卡组生成的ID进行验证AV值；
五、如何接入？
作为卡组织，主要为四方模式中的收单会员和发卡会员提供转接清算等服务，所以在一笔3DS交易中，卡组同样位于收单会员和发卡会员之间，下面仍以接入银联3DS为例，介绍收单机构、发卡行接入银联的3DS业务的步骤。
大家有兴趣也可以登录银联开放平台（https://open.unionpay.com/tjweb/api/detail?apiSvcId=891&index=1）去详细研究；
（一）收单机构
收单机构接入银联3DS，主要有六步：
1. 确认3DS Server的开发方案
支持收单机构自建或者使用三方代理模式；
2. EMVCo认证
3DS Server或3DS SDK组件必须获得EMVCo的认证；
3. 注册会员
如果收单机构还不是银联线上收单会员，必须先申请入会，然后再申请开通银联3DS业务。如果收单机构选择使用三方代理的3DS Server服务，则其合作的三方代理服务商必须申请注册成为银联国际的3DS服务TPSP会员，目前银联与3DS的TPSP包括两类： 3DS Server 服务提供商和 ACS 服务提供商，作为收单机构的3DS三方代理主要是前者；
4. 银联3DS申请
收单机构填写银联标准业务表单，银联将完成表单的审核并完成相关系统的配置；
5. 测试
收单机构需根据银联提供的测试案例及测试要求完成测试；
6. 投产
完成所有测试用例测试后，出具测试报告并申请投产，银联完成生产环境系统配置，完成系统上线和认证；
（二）发卡机构
发卡机构开通银联3DS业务，流程跟收单机构类似，也是六步，当然接口规范等有差别；
1. 确认ACS的开发方案
支持自建或者使用三方代理模式；
2. EMVCo认证
ACS组件必须获得EMVCo的认证；
3. 注册会员
如果发卡机构还不是银联发卡会员，必须先申请入会，然后再申请开通银联3DS业务。如果发卡机构选择使用三方代理的ACS服务，则其合作的三方代理服务商必须申请注册成为银联国际的3DS服务TPSP会员，也就是 ACS 服务提供商；
4-6步同收单机构接入流程一致，可以参考上面的流程；
银联3DS申请：收单机构填写银联标准业务表单，银联将完成表单的审核并完成相关系统的配置；