4. EMV 3DS架构总览
要真正把EMV 3DS接入做稳，不能只记住几个缩写，而要先建立一张“谁负责什么、消息怎么走”的全局图。EMV 3DS的核心目标，是在持卡人、商户、发卡行之间增加一次标准化的身份验证与风险决策过程，同时尽量不打断支付体验。围绕这个目标，协议把职责拆分为若干角色：3DS Server、DS、ACS、MPI、SDK以及各类API。理解它们的边界，是后续风控接入和排障的基础。
核心角色与职责边界
先看各角色的定位。3DS Server是商户侧或收单侧的执行组件，负责生成认证请求、与DS通信、维护事务状态，并把认证结果回传给商户订单系统。DS（Directory Server）是目录服务器，由卡组织提供，核心作用是路由：根据卡号段（BIN）找到对应的ACS，并在3DS Server与ACS之间转发消息。ACS（Access Control Server）由发卡行或其代理提供，负责真正的持卡人身份验证和发卡行侧风险判断，决定放行、挑战还是拒绝。MPI（Merchant Plug-In）是传统3DS 1.0时代的商户插件，在3DS 2.x中其能力通常被3DS Server或支付网关吸收，但很多文档和网关配置里仍保留MPI这一叫法。SDK是集成在商户App或网页中的客户端组件，用于采集设备信息、渲染挑战页面、完成生物识别或OTP交互。API则是3DS Server对外暴露的接口，供商户后端发起认证、查询结果、接收回调。
消息流转全景：从下单到授权
一次典型的3DS 2.x认证，可以拆成“预认证—认证—挑战—结果回传”四个阶段。下面用一条主流程串起来：
- 持卡人在商户下单，商户后端调用3DS Server的API，提交卡号、金额、订单号、设备信息等。
- 3DS Server执行3DS Method（可选），通过DS把请求转发到ACS，ACS返回一个URL，SDK在浏览器或App中加载该URL，采集设备指纹。
- 3DS Server向DS发送AReq（Authentication Request），DS根据BIN路由到对应ACS。
- ACS执行发卡行风控，返回ARes（Authentication Response），其中包含transStatus。若为Y，表示免挑战通过；若为C，表示需要挑战；若为N或R，表示拒绝或失败。
- 若需要挑战，ACS通过DS返回挑战信息，SDK渲染挑战页面，持卡人完成OTP、生物识别或App确认。
- 挑战完成后，ACS生成最终认证结果，经DS回传3DS Server，3DS Server再通知商户系统，商户携带认证数据发起授权。
这条链路里，DS不参与风控决策，只做路由和协议转换；ACS才是决策中心；3DS Server负责状态机和重试；SDK负责端上体验。任何一环超时或字段缺失，都会导致transStatus异常，进而影响授权转化。
关键消息与参数速查
下面这张表把常见消息和核心参数放在一起，便于接入时对照排查。
| 消息/组件 | 方向 | 关键参数 | 作用 |
|---|---|---|---|
| AReq | 3DS Server → DS → ACS | messageVersion、deviceChannel、acctNumber、purchaseAmount、threeDSRequestorAuthenticationInd | 发起认证请求，携带交易与设备上下文 |
| ARes | ACS → DS → 3DS Server | transStatus、authenticationValue、dsTransID、acsTransID | 返回认证结果，供后续授权使用 |
| CReq/CRes | 3DS Server ↔ ACS | challengeData、challengeWindowSize、challengeCompletionInd | 挑战交互，完成持卡人验证 |
| RReq/RRes | 3DS Server → DS | transStatus、errorCode、errorDetail | 结果通知与错误上报 |
| 3DS Method | ACS → SDK | threeDSMethodURL、threeDSMethodData | 设备指纹采集，提升免挑战率 |
案例：一次免挑战与一次挑战的差异
假设商户A接入3DS Server后，遇到两笔交易。第一笔金额较小，ACS风控判定低风险，ARes返回transStatus=Y，同时带回authenticationValue。商户直接拿该值发起授权，用户无感知，转化率高。第二笔金额较大，ACS返回transStatus=C，要求挑战。SDK弹出OTP页面，用户输入验证码后，ACS返回Y。此时商户必须等待最终结果再授权，不能提前放行。
// 伪代码：3DS Server回调处理
if (ares.transStatus === 'Y') {
order.threeDS = { status: 'authenticated', cavv: ares.authenticationValue };
authorize(order);
} else if (ares.transStatus === 'C') {
renderChallenge(ares.challengeData);
} else {
order.threeDS = { status: 'failed', reason: ares.transStatus };
notifyRisk(order);
}
接入复盘：架构视角的三个检查点
第一，路由正确性。DS依赖BIN路由，测试环境与生产环境的BIN范围不同，务必确认卡号段覆盖。第二，状态一致性。3DS Server、商户订单、授权系统三者的状态要能对齐，建议以dsTransID为主键做幂等。第三，超时与重试。DS或ACS超时后，不要盲目重发AReq，应先查询事务状态，避免重复挑战或重复授权。把这三件事做成监控指标，3DS接入的线上问题会显著减少。
整体来看，EMV 3DS的架构并不复杂，复杂的是各角色之间的消息时序和异常分支。把3DS Server当作编排器，DS当作路由器，ACS当作决策器，SDK当作交互端，API当作接入面，再结合transStatus和事务ID做状态管理，就能形成清晰、可运维的接入模型。