2. 支付生态基础
要理解EMV 3DS的认证架构，必须先厘清一笔卡支付从“持卡人点击支付”到“资金入账”之间，究竟有哪些角色参与、各自承担什么职责、彼此如何传递数据与信任。3DS并不是凭空出现的独立系统，它嵌入在既有的四方（或多方）卡支付生态中，只是把“持卡人身份验证”这一环节从商户侧前移到发卡行侧。因此，本节先把生态角色讲清楚，后续的3DS消息流、风控接入点才有落脚之处。
一、核心角色与职责边界
传统卡支付生态最经典的模型是“四方模型”：持卡人、商户、收单行、发卡行，中间由卡组织（如Visa、Mastercard、银联）作为清算与规则中枢。随着线上支付发展，又衍生出PSP（Payment Service Provider，支付服务商）和支付网关（Gateway）等角色，它们把收单能力、技术接入和风控能力打包成服务。
- 持卡人（Cardholder）：账户所有人，发起支付并接受身份验证。在3DS中，持卡人最终在发卡行的验证页面（或发卡行App）完成验证。
- 商户（Merchant）：出售商品或服务的一方，发起支付请求，承担欺诈与拒付风险。商户通常不直接连接卡组织，而是通过PSP或网关接入。
- 收单行（Acquirer）：为商户开立收单账户、受理卡交易的银行或机构。它把商户交易送入卡组织网络，并承担商户侧的部分风险。
- 发卡行（Issuer）：为持卡人发卡、管理账户的银行。它是3DS中真正的“验证决策者”，决定是否对某笔交易发起挑战（Challenge）。
- 卡组织（Card Scheme / Network）：制定规则、提供清算网络、运营3DS目录服务器（DS）。它连接发卡行与收单行，并传递3DS认证结果。
- PSP（Payment Service Provider）：为商户提供支付受理、结算、对账、风控等一站式服务，通常同时具备收单或网关能力。
- 支付网关（Gateway）：负责技术接入与协议转换，把商户系统的支付请求转换为卡组织或收单行可识别的报文，并回传结果。
需要特别强调：PSP与网关不是同一概念。网关偏“通道与技术连接”，PSP偏“服务与资金处理”。很多厂商同时提供两者，但在架构讨论中必须区分，否则在排查3DS超时、认证失败时容易定位错责任方。
二、一笔线上卡支付的角色协作流程
下面以“持卡人在商户网站下单，使用3DS验证”为主线，梳理各角色的协作顺序。注意，3DS的介入点发生在授权（Authorization）之前，属于“认证前置”。
- 持卡人在商户页面提交卡号、有效期等信息，点击支付。
- 商户系统将支付请求发送给PSP或网关。
- PSP/网关判断该卡是否参与3DS，若参与，则向卡组织的目录服务器（DS）发起3DS认证请求。
- DS识别发卡行，将请求路由到发卡行的ACS（Access Control Server，访问控制服务器）。
- ACS根据发卡行风控策略，决定“免挑战（Frictionless）”或“挑战（Challenge）”。
- 若需挑战，持卡人在发卡行页面或App完成验证（OTP、生物识别、App确认等）。
- ACS将认证结果返回DS，DS再返回PSP/网关。
- PSP/网关携带3DS认证结果（CAVV、ECI等）发起授权请求，经收单行进入卡组织网络。
- 发卡行完成授权决策，结果沿原路返回商户，交易完成或拒绝。
三、角色协作关系对照表
为了便于在接入和排障时快速定位责任方，下表把各角色在3DS流程中的核心动作、常见接口和典型风险做了归纳。
| 角色 | 3DS中的核心动作 | 常见接口/协议 | 典型风险或关注点 |
|---|---|---|---|
| 持卡人 | 发起支付、完成挑战验证 | 浏览器/发卡行App | 钓鱼、OTP泄露、设备被控 |
| 商户 | 发起支付、展示3DS跳转或内嵌页面 | 商户后台、3DS SDK/API | 订单篡改、页面劫持、拒付 |
| PSP/网关 | 协议转换、3DS请求转发、结果回传 | 3DS Server、MPI、API | 超时、重试、参数映射错误 |
| 收单行 | 受理交易、送入卡组织、结算 | ISO 8583、卡组织报文 | 商户风险、合规、拒付处理 |
| 卡组织/DS | 路由3DS请求、传递认证结果 | 3DS Protocol、DS服务 | 版本兼容、目录命中率 |
| 发卡行/ACS | 执行风控、发起挑战、返回认证结果 | ACS、3DS Method、Challenge | 策略误判、挑战体验、可用性 |
四、案例与常见误区复盘
假设某商户接入3DS后，发现部分交易频繁出现“认证通过但授权失败”。排查时若只盯着3DS日志，往往会误判为ACS问题。实际上，认证通过后，PSP携带CAVV和ECI发起授权，发卡行可能因为以下原因拒绝：
- 账户余额不足或超过单笔限额；
- 发卡行授权风控认为该商户类别（MCC）异常；
- 3DS认证结果中的ECI值与交易类型不匹配；
- CAVV生成或传递错误，导致发卡行无法校验认证有效性。
再举一个正向案例：某商户希望提升免挑战率以优化支付体验。它通过PSP向发卡行传递更丰富的交易上下文（如设备信息、历史交易、收货地址），发卡行ACS据此判断低风险，直接返回免挑战认证结果。此时商户无需跳转，用户体验接近无3DS，但依然享有3DS的责任转移（Liability Shift）保护。这说明：3DS的价值不仅在于挑战，更在于让发卡行有足够信息做出精准决策。
五、对后续章节的意义
理解这些角色的边界与协作后，后续讨论3DS消息流时，你就能清楚每个报文由谁发出、经过谁、最终到达谁。例如：3DS Method用于收集设备信息，由ACS触发、商户页面配合；AReq/ARes是认证请求与响应，在3DS Server与DS之间传递；CReq/CRes是挑战请求与响应，在ACS与持卡人之间交互。只有先建立生态角色地图，这些缩略语才不会变成孤立的名词。
最后提醒一点：不同卡组织对角色命名和接口细节略有差异，但核心分工一致。接入时以卡组织官方规范为准，同时结合PSP提供的文档，明确每个字段的归属和传递责任，才能避免“认证成功、授权失败、责任不清”的典型问题。