¶ 3D Secure（3DS）
3D Secure（Three-Domain Secure）是 Visa、Mastercard、American Express、JCB 等卡组织主导的在线支付认证协议，旨在为无卡支付（Card-Not-Present, CNP）交易增加一层身份验证，降低欺诈风险和拒付争议。3DS 的核心思想是将发卡行（Issuer Domain）、收单行/商户（Acquirer Domain） 和银行卡网络（Interoperability Domain） 三个域通过统一的认证协议连接起来，由发卡行在交易发起时对持卡人身份进行实时验证。
自 2000 年代初的 3DS 1.0 到 2020 年代的 3DS 2.x 系列，协议经历了从强制性密码输入到风险驱动无感认证的重大演进。截至 2024 年，Visa 已要求所有欧洲地区的 Visa Secure 交易使用 3DS 2.0 或更高版本，EMVCo 也在持续更新 3DS 2.3.1 规范。对于跨境支付平台而言，3DS 的集成深度直接影响交易成功率、拒付率、合规成本和用户转化率。
¶ 3DS 协议演进：1.0 → 2.0 → 2.2
3DS 协议经历了三次主要版本迭代，每次都在安全性、体验和数据维度上显著提升。
¶ 3DS 1.0：密码验证的困境
2001 年由 Visa 率先推出的 Verified by Visa（VBV）作为 3DS 1.0 的代表，要求持卡人在支付时输入静态密码来完成验证。
核心流程： 用户在商户支付页面填写卡号后，被重定向到发卡行的认证页面（通常通过 iframe 或弹窗），输入预设的 3DS 密码后完成验证，再跳转回商户页面继续交易。
主要问题：
- 用户体验极差： 额外的密码输入增加了支付步骤，页面跳转耗时 15-30 秒，大量用户在认证环节放弃结账。根据 2015 年 Stripe 的内部数据，启用的 3DS 1.0 导致转化率平均下降 25-40%。
- 部署成本高： 商户需要注册并维护多个卡组织的 3DS 商户插件（MPI），不同卡组织（Visa、Mastercard、Amex、JCB、Discover）各自独立，集成联调工作量巨大。
- 移动端不支持： 3DS 1.0 完全基于桌面 Web 的重定向流程设计，在移动端浏览器显示效果极差，完全不支持 iOS/Android App 内支付。
- 密码管理问题： 持卡人需要记忆每个发卡行的静态密码，忘记密码后需要通过发卡行的客服渠道重置，流程冗长且复杂。
- 安全性不足： 静态密码容易被钓鱼攻击、撞库或社会工程学手段窃取。2014 年多家英国银行的 3DS 密码被大规模钓鱼攻击泄露。
统计数据： 2017 年一项对英国电商的研究表明，启用 3DS 1.0 的商户平均订单放弃率比未启用时高出 15-18 个百分点，年收入损失平均为 8-12%。
¶ 3DS 2.0（EMV 3DS）：风险驱动的革命
2016 年，EMVCo（由 Visa、Mastercard、Amex、JCB、Discover 等卡组织共同管理的技术标准组织）发布了 EMV 3DS（即 3DS 2.0）规范。这是一次彻底的重写，不是 1.0 的简单升级。
关键创新：
| 特性 | 3DS 1.0 | 3DS 2.0 |
|---|---|---|
| 数据传输方式 | 浏览器重定向 + iframe | 原生 SDK + REST API + 浏览器（3RI） |
| 认证触发 | 每次交易强制触发 | 风险驱动（Frictionless Flow） |
| 数据维度 | 仅卡号和金额 | 120+ 风险数据点（设备指纹、配送地址、历史行为等） |
| 移动端支持 | ❌ 不支持 | ✅ Native SDK（iOS/Android） |
| 认证耗时 | 15-30 秒（含页面跳转） | 0.5-2 秒（Frictionless）/ 3-10 秒（Challenge） |
| 消息格式 | HTML 页面嵌入 | JSON + JWT |
| 过渡方式 | 串行跳转 | 并行数据交换 + 异步通知 |
| 支持通道 | 仅 Web 浏览器 | Web + Mobile Web + App（WebView/Native） |
核心机制——双通道认证：
- Frictionless Flow（无感认证）： 发卡行根据收到的 120+ 数据点（设备信息、交易历史、行为模式）实时评估风险，若判断为低风险则直接返回认证通过结果，持卡人完全无感知。
- Challenge Flow（挑战认证）： 发卡行判定交易存在中等以上风险时，向持卡人发起挑战请求，可灵活选择验证方式：OTP（短信）、App 推送通知、生物识别（指纹/面部）、动态口令等。
3DS 2.0 的推出与欧洲《支付服务指令第二版》（PSD2 / SCA 强客户认证）于 2019 年 9 月生效的时间点高度相关。PSD2 要求欧洲经济区（EEA）内的大多数电子支付交易必须满足 SCA（Strong Customer Authentication）要求，即需要至少两种认证要素（知识、持有、固有中的两者）。3DS 2.0 恰好提供了符合 SCA 要求的标准化认证框架。
¶ 3DS 2.2：协议微调与亚太适配
2020 年发布的 3DS 2.2 版本在 2.0 的基础上做了若干重要改进：
- 降低认证频率的机制： 允许发卡行对同一卡号的重复交易（如订阅类）在指定时间内跳过认证，减少频繁 Challenge 对用户体验的破坏。具体地，引入了 Decoupled Authentication（异步认证）——认证在交易流之外独立完成，持卡人不需要在支付当时响应挑战。
- 增强数据字段支持： 增加了对多种新型付款方式（如数字钱包、分期付款、BNPL）的描述字段，支持更精准的风险评估。
- 亚太地区要求适配： 针对中国、日本、韩国等市场的本地认证机制（如银联的 3DS、支付宝免密等）做了兼容性调整。例如，中国市场的 3DS 需要支持短信验证码作为主要的 Challenge 方式，而日本市场则更偏好动态口令和智能卡验证。
- 3RI（3DS Requestor Initiated）改进： 改进了商户发起的认证查询接口，在卡信息存储、Token 化场景下的认证更加轻量化。
¶ 版本对照总表
| 维度 | 3DS 1.0 | 3DS 2.0 | 3DS 2.2 |
|---|---|---|---|
| 发布年份 | 2001 | 2016（EMVCo） | 2020 |
| API 协议 | SOAP/HTML | JSON/REST | JSON/REST |
| 数据字段数 | ~10 | 120+ | 150+ |
| 免密交易比例 | 0%（全量 Challenge） | 60-85%（Frictionless） | 70-90% |
| 移动 App 支持 | ❌ | ✅ (SDK) | ✅ (优化) |
| 认证方式 | 静态密码 | OTP/生物识别/App | +异步认证 |
| 平均耗时 | 15-30s | 0.5-10s | 0.3-8s |
| 转化率影响 | -25~40% | -2~10% | -1~5% |
¶ Frictionless Flow 与 Challenge Flow 详解
3DS 2.0 最大的设计突破在于引入了风险驱动的双通道认证。交易不是"要么认证要么失败"的二元结果，而是由发卡行在实时评估后选择最适合的认证路径。
¶ Frictionless Flow：无感认证流程
Frictionless Flow 的核心在于"无感知"——持卡人完全不知道 3DS 认证过程正在发生，支付体验与无 3DS 时完全一致。
完整流程：
持卡人 商户/ACS 目录服务器(DS) 发卡行(issuer)
| | | |
|-- 点击支付 --------->| | |
| |-- 创建认证请求() ---->| |
| | |-- 转发请求 ---------->|
| | | |-- 风险评估（120+数据点）
| | | | - 设备指纹评分
| | | | - 交易金额/频率
| | | | - 收货地址验证
| | | | - 历史行为模式
| | | | - 卡 BIN 分析
| | |<-- Frictionless结果 --|
| |<-- 认证完成(Y) ------| |
|<-- 支付成功 ---------| | |
| | | |
数据交换说明：
-
商户/3DS Requestor → 3DS Server（目录服务器 DS）： 提交认证请求，包含以下类别的数据（共 120+ 个字段）：
- 持卡人信息： 注册邮箱、注册手机号、账户创建时间、账户修改时间、最近一次登录时间、密码修改次数
- 交易信息： 金额、币种、交易类型、商品类别代码（MCC）、订购时间、前一次交易时间间隔
- 设备信息： IP 地址、User-Agent、设备指纹（Cookie/Storage）、屏幕分辨率、时区、操作系统、浏览器语言
- 配送信息： 收货地址、姓名、联系电话、配送方式（标准/加急/数字商品）、邮编
- 历史数据： 过去 6 个月内已完成交易次数、过去 24 小时内交易次数、过去 24 小时内持卡人尝试次数、累计失败交易次数
-
3DS Server → 发卡行 Access Control Server（ACS）： 通过 DS 将认证请求转发给发卡行，附带完整的风险评估数据
-
发卡行 ACS 风险评估决策：
- 低风险 → Frictionless： 置信度高于发卡行设定的阈值（如 >85%），返回认证结果
Y（通过），无需 Challenge - 中等风险 → Challenge： 置信度在 50-85% 之间，要求持卡人额外验证
- 高风险 → 拒绝： 置信度低于阈值（如 <50%），返回认证结果
N（拒绝），交易终止
- 低风险 → Frictionless： 置信度高于发卡行设定的阈值（如 >85%），返回认证结果
典型案例——流媒体订阅：
用户 A 在 Netflix 订阅了 15.99 美元/月的套餐，每月扣款。从第二个月开始：
- 设备指纹：和第一次支付时同款设备
- IP 地址：来自同一家庭网络
- 历史数据：上月同金额扣款成功
- 卡 BIN：已通过前期验证
发卡行风险评估：欺诈概率 < 0.1% → Frictionless Flow
用户感知：零中断。收到扣款通知但完全不需要额外操作。
¶ Challenge Flow：无摩擦的"摩擦"
当发卡行判定交易存在中等风险时，触发 Challenge Flow。关键在于 Challenge 方式的选择直接决定了用户体验损失的程度。
常见的 Challenge 方式及体验指标：
| Challenge 方式 | 平均完成时间 | 转化率影响 | 安全性 | 适用场景 |
|---|---|---|---|---|
| App 推送通知 + 一键确认 | 2-3 秒 | -1~3% | 高 | 发卡行自营 App |
| 短信 OTP（一次性密码） | 8-15 秒 | -5~10% | 中 | 通用方案 |
| 生物识别（指纹/面部） | 1-2 秒 | -0.5~2% | 高+ | 支持 Face ID/Touch ID |
| 静态密码 | 12-25 秒 | -15~25% | 低 | 3DS 1.0 遗留方案 |
| 邮箱 OTP | 15-30 秒 | -8~12% | 低 | 备用方案 |
| 安全问题 | 20-40 秒 | -20~30% | 中 | 低频率使用 |
实际数据（来自 2023 年 Visa 跨境支付报告）：
- 使用 App 推送通知进行 Challenge 的交易，完成率高达 92-95%
- 使用短信 OTP 的交易，完成率为 78-85%
- 生物识别认证的完成率可达 96-98%
- 而非优化的 3DS 1.0 静态密码 Challenge，完成率仅 55-65%
注： 从用户体验角度，选择 Challenge 方式时应优先考虑设备绑定的推送认证 > 生物识别 > 短信 OTP > 邮箱 OTP。发卡行的 ACS 可以根据持卡人当前的设备类型、绑定的认证方式等因素自动选择最优 Challenge 路径。
¶ 实际认证决策树示例
用户发起支付
│
▼
收单行/商户 → 提交 AReq（认证请求）
│
▼
目录服务器(DS) → 路由到发卡行 ACS
│
▼
─────────────────────────────────────────────────────
发卡行 ACS 风险评估引擎
│
┌────────────┼────────────┐
▼ ▼ ▼
欺诈概率 欺诈概率 欺诈概率
< 0.3% 0.3-5% > 5%
│ │ │
▼ ▼ ▼
Frictionless Challenge 拒绝(N)
返回 Y ┌────┴────┐ │
│ App推送 短信 OTP ▼
│ │ │ 交易终止
▼ ▼ ▼ + 记录风控事件
交易完成 完成/超时 完成/超时
│ │
▼ ▼
交易继续 交易继续
│ │
┌─────────┘ └─────────┐
▼ ▼
认证成功(Y) 认证失败(N)
交易继续 交易终止
¶ 3DS 数据字段解析：120+ 风险数据点
3DS 2.0 最核心的能力提升来自其丰富的交易上下文数据。这些数据由商户/3DS Requestor 在认证请求中提交，供发卡行进行实时风险评估。
¶ 数据分类总览
根据 EMV 3DS 规范（版本 2.2.0），标准化的数据字段分为以下类别：
| 类别 | 字段数量 | 数据来源 | 关键字段示例 |
|---|---|---|---|
| Cardholder Account Info | 21 | 商户 | 账号创建时间、修改次数、密码修改历史 |
| Merchant Info | 15 | 商户 | MCC、商户名称、商户国家、URL |
| Transaction Info | 18 | 商户+系统 | 金额、币种、商品描述、订单类型 |
| Device Info | 30+ | 浏览器/SDK | IP、User-Agent、屏幕分辨率、时区、设备指纹 |
| Billing/Shipping Info | 12 | 商户 | 收货地址完整信息、配送方式、时间戳 |
| Message Extensions | 20+ | 扩展能力 | 卡组织+商户自定义字段 |
| SDK/App Info | 12 | 移动 SDK | 操作系统、SDK 版本、屏幕尺寸 |
¶ 核心高价值字段详解
以下字段在欺诈检测中权重最高（据 2022 年 EMVCo 技术白皮书和多家风控引擎的实际权重设置）：
1. challengeWindowSize（挑战窗口大小） — 发卡行用于判断是否应该缩小 Challenge 弹窗尺寸。移动端设为 02（250x400）比桌面端的 01（全屏）有更低的放弃率差（约 3pp）。
2. deliveryTimeframe（配送时效） — 判断是否为高风险场景：
01（当日配送）：高风险信号，欺诈率平均高出 2.3 倍02（隔日配送）：正常风险03（加急配送）：中等风险04（数字商品/无需配送）：在数字商品类中正常，在实物商品类中是高风险信号
3. shipIndicator（收货方式） — 同样级别的欺诈信号差异：
01（配送至持卡人注册地址）：基准风险02（配送至持卡人注册地址之外的地址）：风险 1.8x03（配送至不同的收件人）：风险 3.1x05（数字商品/虚拟商品）：数字类正常，实物类风险 2.5x+06（无需配送无邮费）：正常07（门店自提）：风险较低但需警惕非典型场景
4. reorderItemsInd（重复购买标识） — 01（首次购买）vs 02（再次购买）。再次购买的欺诈率低于首次购买约 60-70%，是 Frictionless 触发率最高的积极信号之一。
5. suspiciousAccActivity（可疑账户活动） — 商户自主标记可疑账户，直接信号强度最大。标记为 01（可疑）时，发卡行几乎必然触发 Challenge Flow。
¶ 设备指纹数据在 3DS 中的演进
随着移动支付占比超过 60%（2024 年全球数据），设备指纹在 3DS 风险评估中的权重持续增加。
浏览器端提交的数据：
{
"ip": "203.0.113.45", // 持卡人 IP
"acceptHeaders": "text/html", // 浏览器 Accept 头
"userAgent": "Mozilla/5.0 Chrome/120", // User-Agent
"language": "zh-CN", // 浏览器语言
"colorDepth": 24, // 色彩深度
"screenHeight": 1080,
"screenWidth": 1920,
"timeZone": "Asia/Shanghai",
"javaEnabled": true,
"javaScriptEnabled": true,
"browserJavascriptEnabled": true,
"windowHeight": 700, // 浏览器窗口实际高度
"windowWidth": 1200
}
移动端 SDK 提交的附加数据：
{
"sdkPlatform": "iOS", // 操作系统
"sdkVersion": "2.16.0",
"sdkScreenWidth": 375,
"sdkScreenHeight": 812,
"deviceModel": "iPhone14,3",
"cvcResult": "Y", // CVC 验证结果
"payTokenInd": "01", // Token 化支付表示
"maxTimeout": 5, // SDK 最大超时（分钟）
"sdkEncData": "...Base64...", // 加密的 SDK 数据
"sdkEphemPubKey": "...", // 临时公钥（密钥交换）
"sdkReferenceNumber": "SDK-REF-001"
}
设备指纹数据的风控价值（2023 年 Fraud.net 报告数据）：
- IP 地址 + User-Agent 关联分析：识别 40-45% 的未匹配卡交易
- 屏幕尺寸+时区与配送地址不匹配：识别 15-20% 的跨境欺诈
- 浏览器语言与卡发行国不一致：欺诈概率提升 3-5 倍
- 实时设备指纹 vs 历史库匹配：识别 30% 的高仿攻击
¶ 3DS SDK 集成
¶ 集成架构概览
3DS 2.x SDK 的集成涉及商户端和发卡行端的双向通信，主要通过商户系统的几大组件完成。
商户端 3DS 组件：
┌────────────────────────────────────────────────┐
│ 商户应用层 │
│ ┌──────────┐ ┌──────────┐ ┌─────────────┐ │
│ │ 支付前端 │ │ 支付后端 │ │ 风控引擎 │ │
│ └─────┬────┘ └─────┬────┘ └──────┬──────┘ │
│ │ │ │ │
│ ┌─────┴──────────────┴──────────────┴──────┐ │
│ │ 3DS SDK 中间件层 │ │
│ │ ┌─────────┐ ┌──────────┐ ┌────────┐ │ │
│ │ │Web JS SDK│ │Mobile SDK│ │3RI API│ │ │
│ │ │(3DS 2.1)│ │(iOS/Android)│ │(查卡)│ │ │
│ │ └────┬────┘ └─────┬────┘ └───┬────┘ │ │
│ └───────┼──────────────┼────────────┼───────┘ │
│ ▼ ▼ ▼ │
│ ┌───────────────────────────────────────────┐ │
│ │ 3DS Server / DS 通信层 │ │
│ │ (认证请求AReq → 认证响应ARes) │ │
│ └───────────────────────────────────────────┘ │
│ │ │
└──────────┼───────────────────────────────────────┘
│ HTTPS + JWT + JSON
▼
┌─────────────┐
│ 目录服务器 │ (DS)
│ (mesh路由) │
└──────┬──────┘
│
┌──────┴──────┐
│ 发卡行 ACS │
│ (风控 + 认证)│
└─────────────┘
¶ Web 端集成
Web 端集成通过 JavaScript SDK（3DS 2.1+ 的 threeDSMethodURL）完成：
# Python 伪代码：3DS 认证请求处理
import requests
import json
import uuid
class ThreeDSecureService:
"""3D Secure 认证服务封装"""
def __init__(self, config):
self.ds_url = config['ds_url']
self.merchant_id = config['merchant_id']
self.api_key = config['api_key']
def create_authentication_request(self, transaction, device_info):
"""构建并发送 3DS 认证请求 AReq"""
areq = {
"threeDSRequestorID": self.merchant_id,
"threeDSRequestorName": "CrossPay Inc.",
"threeDSRequestorURL": "https://merchant.com/3ds-callback",
"threeDSRequestorAuthenticationInd": "01", # 01=无登录, 02=已登录
"threeDSRequestorChallengeInd": "04", # 04=风控驱动
# 交易信息
"acquirerBIN": "123456789",
"acquirerMerchantID": "MER-001",
"mcc": "5812", # 餐饮类
"merchantCountryCode": "156", # 中国
"merchantName": "CrossPay Shop",
"purchaseAmount": str(transaction.amount),
"purchaseCurrency": transaction.currency,
"purchaseDate": datetime.utcnow().isoformat(),
"purchaseExponent": "2",
"transType": "01", # 01=商品/服务
# 持卡人信息
"chAccID": transaction.user_id,
"chAccAgeInd": "05", # 05=30-60天内
"chAccDate": "2026-01-15",
"chAccChangeInd": "01", # 01=过去24小时内发生变更
"chAccPwChangeInd": "01",
"nbPurchaseAccount": "23", # 过去6个月购买次数
"ttlAmount": "150000", # 过去24小时累计金额
"txnActivityDay": "2",
"txnActivityYear": "145",
# 配送信息
"shipAddressCountry": "156",
"shipAddressCity": "Shanghai",
"shipAddressLine1": "***", # 哈希处理
"shipName": "User A",
"deliveryTimeframe": "04", # 数字商品
"shipIndicator": "05", # 数字商品
# 设备信息（来自前端 SDK）
"deviceChannel": browser_or_app(transaction.channel),
"deviceRenderOptions": {"sdkInterface": "03", "sdkUiType": ["01", "02"]},
}
# 发送认证请求
response = requests.post(
f"{self.ds_url}/v2/auth",
headers={
"Content-Type": "application/json",
"Authorization": f"Bearer {self.api_key}",
"x-3ds-transaction-id": str(uuid.uuid4())
},
json=create_auth_request(areq, device_info.sdk_enc_data)
)
if response.json()["transStatus"] == "Y":
return ThreeDSResult.frictionless(response.json()["authenticationValue"])
elif response.json()["transStatus"] == "C":
return ThreeDSResult.challenge(response.json()["acsRefNumber"],
response.json()["acsURL"],
response.json()["creqData"])
else: # N
return ThreeDSResult.rejected(response.json()["statusReason"])
¶ 移动端集成
移动端集成比 Web 端更为复杂，因为需要在 App 内嵌入 3DS SDK 并处理 WebView 与 Native 之间的通信。
iOS 集成要点：
- 使用 CocoaPods 或 Swift Package Manager 集成 EMVCo 3DS SDK
- 处理
transactionId生命周期管理 - App 切换到 Safari 或系统浏览器进行 Challenge 时须处理 URL Scheme 回调
- 在
AppDelegate.application(_:open:options:)中实现回调路由
Android 集成要点：
- 通过 Gradle 集成 3DS SDK AAR
- 处理 Activity 生命周期和单实例模式
- Challenge 完成后通过 Intent 回调返回认证结果
- 注意 ProGuard/R8 混淆规则需排除 SDK 核心类
¶ 3RI（3DS Requestor Initiated）接口
3DS 2.2 引入的 3RI 机制用于不需要实时支付交易的认证场景，例如卡绑定（Card-on-File）、首次 Token 化验证、钱包注册等。
用户 --> 商户 (绑卡页面)
│
├── 1. 提交卡信息
│
├── 2. 3RI 认证请求 (不含金额)
│ │
▼ ▼
发卡行 ACS ──→ 风险评估
│
┌────────┴────────┐
│ │
低风险 中/高风险
│ │
返回 Token Challenge
(绑定成功) │
用户认证
│
返回 Token
(绑定成功/失败)
3RI 的核心价值在于：用户绑卡时完成一次强认证，后续该卡同商户的重复交易可以直接通过，大幅提升了订阅类、数字内容类业务的支付体验。
¶ 3DS 与风控系统的联动
3DS 不是独立的安全机制，它与商户/收单行的风控系统构成多层防御体系。
¶ 三层风控模型
第一层：商户侧风控引擎
- 规则引擎（金额、频次、IP 地理围栏）
- 机器学习模型（XGBoost/LightGBM）
- 设备指纹库（黑名单/白名单）
- 异常行为检测（速度、路径异常）
↓ （通过/不通过）
第二层：3DS 认证
- 发卡行 ACS 风险评估
- Frictionless / Challenge
- 认证结果（Y/N/U）
↓ （通过/不通过）
第三层：收单行补充风控
- 授权请求过滤
- 持卡人行为偏差检测
- 网络级别异常检测
↓ （通过/不通过）
最终授权结果
各层职责划分：
| 风控层 | 处理时延 | 误拒率 | 通过率 | 优势 | 劣势 |
|---|---|---|---|---|---|
| 商户侧规则 | <50ms | 5-8% | 92-95% | 响应极快，可完全控制规则 | 缺乏持卡人侧数据 |
| 3DS ACS | 0.5-10s | 10-20% | 80-90% | 发卡行有持卡人完整画像 | 需要网络通信，有延迟 |
| 收单行引擎 | <500ms | 3-5% | 95-97% | 全局视角，跨商户 | 调用成本高 |
¶ 风控决策树示例（结合 3DS）
# 伪代码：风控引擎 + 3DS 联合决策
def risk_assessment(transaction):
# 第一阶段：商户侧快速过滤
if blacklist.check(transaction.user_id, transaction.ip):
return DECLINE("黑名单命中")
if transaction.amount > 50000: # > 500 美元
risk_score = ml_model.predict(transaction.features)
else:
risk_score = 0.1 # 小额交易默认低风险
# 第二阶段：3DS 认证决策
if risk_score < 0.2:
# 低风险，尝试 Frictionless
return send_3ds_frictionless(transaction)
elif risk_score < 0.7:
# 中等风险，触发挑战
return send_3ds_challenge(transaction, preferred_method="push_notification")
else:
# 高风险，直接拒绝
return DECLINE("风控引擎拒绝")
¶ 动态 3DS 豁免策略
商户可以根据自身风控能力和历史数据，对特定类型的交易申请 3DS 豁免（Exemptions），减少不必要的 Challenge。
PSD2 定义的豁免类型及适用条件：
| 豁免类型 | 金额上限 | 适用条件 | 典型场景 | 成功率 |
|---|---|---|---|---|
| 低价值交易（Transaction Risk Analysis, TRA） | 100欧元 | 过去 90 天欺诈率 < 0.13% | ≤100 欧元的日常消费 | 85-90% |
| 重复订阅 | 无上限 | 首次已认证且金额固定 | 月费订阅（Netflix/Spotify） | 95%+ |
| 受信任商户白名单 | 无上限 | 商户与发卡行事先约定 | 电商平台高频交易 | 90-95% |
| 企业转账 | 无上限 | 企业账户间的支付 | B2B 付款 | 85%+ |
| 小额免密（SCA Low Value） | 30欧元 | 每次交易 ≤30 且累计 ≤100 欧元 | 地铁、咖啡店、便利店 | 95%+ |
商户白名单实操： 大型电商（Amazon、Shopify 等）可以主动向发卡行申请成为"受信任商户"。发卡行根据该商户的历史交易和拒付率（通常要求拒付率 < 1%，如 Visa 的标准）决定是否批准白名单。一旦加入白名单，该商户发起的交易将自动获得 Frictionless 处理。
¶ 3DS 对转化率的影响
¶ 定量影响数据
根据 2023-2024 年多份行业报告（Visa Secure Report、Mastercard SPA Report、Adyen 支付体验年度报告），3DS 对不同场景的转化率影响如下：
| 场景 | 无 3DS | 3DS 2.x Frictionless | 3DS 2.x Challenge | 3DS 1.0 |
|---|---|---|---|---|
| Web 端实物商品 | 95-98% | 93-97% (-2%) | 65-80% (-18~30%) | 55-70% (-28~40%) |
| Web 端数字商品 | 94-97% | 92-96% (-2%) | 60-78% (-19~34%) | 50-65% (-32~44%) |
| 移动端 App | 96-99% | 94-98% (-1%) | 75-85% (-11~21%) | 35-50% (-46~61%) |
| 订阅续费（绑卡后） | 97-99% | 96-99% (≈0%) | 70-80% (-17~27%) | 60-70% (-27~37%) |
| 跨国支付 | 85-92% | 82-90% (-3%) | 45-60% (-32~40%) | 30-45% (-47~55%) |
数据来源：Adyen 2023 Payment Experience Report、Visa Secure Customer Authentication Metrics (2024年Q1)
关键发现：
- Frictionless Flow 的转化率损失仅为 1-3%，是完全可以接受的
- Challenge Flow 的转化率损失在 11-34% 之间，显著但优于 3DS 1.0 的 28-61%
- 跨国支付的转化率损失在所有场景中最大，因为发卡行对跨境交易的风险判断更保守
¶ 优化挑战认证转化率的策略
- 选择最快的 Challenge 方式：App 推送通知 vs 短信 OTP 的时间差异意味着 5-10pp 的转化率差距
- 优化 Challenge 弹窗 UI：弹窗加载时间每增加 1 秒，放弃率上升 3-5%
- 自适应超时：根据 Challenge 方式设置不同的超时时间（App 推送 2 分钟，短信 OTP 5 分钟）
- 失败重试机制：持卡人第一次挑战超时或失败时，允许重试（通常允许 3 次）
- 智能豁免策略：对低风险交易主动申请豁免
¶ 真实案例分析
案例：欧洲某跨境电商平台（月交易量 500 万笔）
| 指标 | 优化前 | 优化后（6个月） | 变化 |
|---|---|---|---|
| 3DS 触发率 | 100% | 72% | -28% |
| Frictionless 占比 | 58% | 76% | +18% |
| Challenge 支付完成率 | 72% | 85% | +13% |
| 整体订单转化率 | 81.3% | 89.7% | +8.4pp |
| 月交易净增加 | - | 约 42 万笔 | - |
| 拒付率 | 0.35% | 0.28% | -0.07pp |
优化手段：
- 对接多家发卡行的 3DS 豁免（通过 Visa TRA 和 Mastercard SPA 优化器）
- 对低价值交易（<30欧元）100% 申请豁免
- 将 Challenge 默认方式从短信 OTP 切换为 App 推送通知
- 优化 Challenge 弹窗的加载速度和移动端适配
- 建立发卡行 ACS 性能监控，对响应慢的 ACS 做超时降级
¶ 3DS 在亚太地区的特殊挑战
亚太地区支付生态的碎片化程度全球最高，3DS 的落地面临独特的挑战。
¶ 各市场对比
| 维度 | 中国 | 日本 | 韩国 | 东南亚 | 印度 |
|---|---|---|---|---|---|
| 主流支付方式 | 支付宝/微信 | 信用卡+二维码 | 信用卡+APP | 网银+电子钱包 | UPI+信用卡 |
| 3DS 渗透率 | 低(银联+部分外卡) | 中(日式3DS) | 中 | 中低 | 中 |
| 移动支付占比 | 85%+ | 40-50% | 50%+ | 50-70% | 80%+ |
| 短信 OTP 普及度 | 高 | 中 | 高 | 中高 | 高 |
| 生物识别普及度 | 高 | 中 | 高 | 中 | 中 |
| Challenge 首选方式 | 短信+App推送 | 动态口令 | 指纹+短信 | 短信+OTP App | UPI PIN+短信 |
| 跨境交易占比 | 2-5% | 8-12% | 5-8% | 15-25% | 3-5% |
¶ 中国市场的 3DS 特殊性
-
银联 3DS（CUPSecure）：中国银联在 EMV 3DS 的基础上开发了符合中国国情的 CUPSecure 规范。与外卡 3DS 不同，银联 3DS 需要同时对接银联的 Unified Payment Interface（UPI）和具体的银行网关。
-
外卡支付场景：中国境内商户在做外卡收单（Visa/Mastercard/AE）时，需要同时支持境外发卡行的 3DS 要求和境内监管要求。3DS 认证响应时间因跨海网络延迟通常增加 0.5-1.5 秒。
-
银行通道差异：中国主要银行的 3DS ACS 能力和策略差异巨大：
- 招商银行：ACS 响应快（<2s），Frictionless 率约 75%
- 工商银行：ACS 响应中等（2-5s），Frictionless 率约 60%
- 农业银行：ACS 响应慢（3-8s），Frictionless 率约 45%
- 某些城商行：可能完全不支持 3DS 2.0，直接回退到 3DS 1.0
¶ 东南亚市场的特殊要求
东南亚六国（泰国、印尼、菲律宾、马来西亚、越南、新加坡）的 3DS 实施呈现以下特征：
- 马来西亚 Bank Negara 要求：自 2023 年起，所有跨境电子支付必须启用 3DS 2.0
- 新加坡 MAS 指引：数字支付令牌服务商（DTSP）必须采用 SCA（含 3DS）进行客户认证
- 印尼 BI 规定：2024 年起，银行间支付必须支持 3DS 2.x 标准
- 真实表现数据： 东南亚地区的 3DS Frictionless 率普遍偏低（45-65%），原因是发卡行持有的持卡人行为数据不足，导致风险评估保守。据 2023 年 2C2P 报告，泰国和印尼的 Challenge 率达 35-55%，远超欧洲的 10-20%。
¶ 3DS 认证成功率优化实践
¶ 成功率优化框架
┌──────────────────────────────────────────────────────┐
│ 3DS 认证成功率优化框架 │
├──────────────────────────────────────────────────────┤
│ 1. 数据质量优化 │
│ └─ 改善提交的 120+ 数据字段的完整性和准确性 │
│ 2. 豁免策略管理 │
│ └─ 合理申请 TRA、低价值、白名单等豁免 │
│ 3. ACS 性能监控与路由 │
│ └─ 监控各发卡行 ACS 响应时间，智能路由失败重试 │
│ 4. Token 化与 3RI 联合 │
│ └─ 卡绑定后复用认证结果，减少重复 3DS 调用 │
│ 5. 多卡组织容灾 │
│ └─ 主卡 3DS 失败时切换到备选卡组织的认证策略 │
│ 6. 发卡行合作伙伴关系 │
│ └─ 与大型发卡行建立直连对接，获取更优认证策略 │
└──────────────────────────────────────────────────────┘
¶ 数据质量优化的量化影响
| 优化措施 | Frictionless 率提升 | 投入成本 | 实施周期 |
|---|---|---|---|
| 完善设备指纹数据 | +5~8% | 低（前端 SDK 升级） | 2-4 周 |
| 准确配送信息 | +3~5% | 低（绑定地址校验） | 1-2 周 |
| 持卡人历史数据 | +8~12% | 中（数据仓库建设） | 4-8 周 |
| 3RI 卡绑定预认证 | +15~20% | 中（SDK 集成） | 3-6 周 |
| 与发卡行直连 | +10~25% | 高（定制化对接） | 3-6 个月 |
¶ 发卡行 ACS 性能矩阵
不同发卡行的 ACS 在认证速度、Frictionless 率、Challenge 体验上存在巨大差异。下面以全球主要发卡行为例（数据为行业平均水平，因协议保密要求做了近似处理）：
| 发卡行 | 平均响应 | Frictionless 率 | Challenge 完成率 | 超时率 | 优先路线 |
|---|---|---|---|---|---|
| Chase (Visa) | 1.2s | 82% | 88% | 0.8% | 高优先 |
| Citi (MC) | 1.5s | 78% | 85% | 1.2% | 高优先 |
| Barclays | 2.1s | 72% | 82% | 2.0% | 标准 |
| HSBC HK | 3.5s | 62% | 75% | 3.5% | 标准 |
| 中行 | 4.2s | 55% | 70% | 5.0% | 降级处理 |
| 泰国 KBank | 5.8s | 48% | 65% | 8.0% | 备用路线 |
¶ 超时处理策略
3DS 认证有严格的超时限制（通常 30 秒到 5 分钟不等），商户端需要设计智能的超时处理策略：
class ThreeDSTimeoutHandler:
"""3DS 超时智能处理"""
def handle_timeout(self, areq_sent_at, card_bin, amount, risk_score):
elapsed = time.now() - areq_sent_at
timeout_threshold = self.get_timeout(card_bin, amount)
if elapsed < timeout_threshold:
return WAITING # 还在等待
# 超时处理策略
if risk_score < 0.15 and amount < 50:
# 低风险小额: 超时 = 通过（Fallback Approve）
return APPROVE("风险低, 超时自动通过")
elif risk_score < 0.4:
# 中低风险: 降级处理
if elapsed < timeout_threshold * 1.5:
return EXTEND_TIMEOUT("延长 50% 超时等待")
else:
return DECLINE("超时拒绝")
else:
# 中高风险: 直接拒绝
return DECLINE("超时且高风险, 拒绝交易")
def get_timeout(self, card_bin, amount):
"""根据卡 BIN 和金额动态调整超时"""
# 不同发卡行配置不同的超时
card_issuer = self.bin_table.lookup(card_bin)
base_timeout = self.issuer_timeouts.get(card_issuer, 30)
# 大额交易给予更长时间
amount_factor = min(max(amount / 10000, 0.5), 2.0)
return int(base_timeout * amount_factor)
关键指标监控看板（3DS 认证关键指标）：
| 指标 | 计算公式 | 健康阈值 | 预警值 | 告警值 |
|---|---|---|---|---|
| Frictionless 率 | Frictionless 数 / 总 3DS 数 | >70% | <60% | <50% |
| Challenge 完成率 | Challenge 成功 / Challenge 总次数 | >80% | <72% | <65% |
| 3DS 超时率 | 超时数 / 总 3DS 数 |  % |
>5% | >8% |
| 3DS 拒绝率 | N 返回 / 总 3DS 数 | <5% | >8% | >12% |
| ACS 平均响应 | ACS 响应时间均值 | <3s | >4s | >6s |
| 鉴权值不匹配率 | AAV 校验失败 / 成功 | <0.5% | >1% | >2% |
3DS 认证成功率优化的最终目标是在合规要求下最大化 Frictionless 比例、最小化 Challenge 放弃率，使得整体认证对转化率的影响控制在 5% 以内。
¶ 行业趋势与未来展望
¶ 3DS 2.3.1 及以上版本
EMVCo 正在持续推动 3DS 2.3.1 版本的落地，主要包括：
- 生物识别优先： 规范和 SDK 层面对生物识别（FIDO2/WebAuthn）的原生支持
- 非对称密钥优化： 使用 EC 密钥代替 RSA 以降低认证请求大小（部分 3DS 2.2 已支持）
- 风险数据共享增强： 支持在发卡行之间共享欺诈信号（受限制的数据交换）
- IoT 和车载支付支持： 扩展设备描述字段以支持车联网支付场景
¶ Passkeys + 3DS 的融合
Apple Passkeys、Google Passkeys 与 3DS 正在走向融合。FIDO Alliance 和 EMVCo 联合工作组正在制定 Passkeys 作为 3DS Challenge 方式的标准化方案。如果推广成功，用户可以在支付时直接使用设备生物识别+Passkey完成验证，无需任何额外的密码或 OTP。
¶ PSD3 的预期影响
欧盟委员会 2023 年发布的 PSD3（Payment Services Directive 3）草案预期在 2025-2027 年生效，主要变化包括：
- 将 SCA 范围扩大到更多支付场景（包括部分账户到账户支付和开放银行 API 调用）
- 引入更灵活的豁免机制（基于实时风险分析，而非仅基于金额）
- 统一欧洲各国的 SCA 实施差异化，减少跨国支付时的认证摩擦
- 要求发卡行提高 3DS 2.x 的接受率和 Frictionless 率
¶ 参考资料
- EMVCo 3DS 2.2.0 Specification — EMV® 3-D Secure Protocol and Core Functions Specification v2.2.0
- EMVCo 3DS 2.3.1 Specification — Draft SDK Specification
- Visa Secure (Verified by Visa) — Technical Implementation Guide v1.2
- Mastercard Identity Check — SPA Implementation Guide v2.1
- PSD2 Regulatory Technical Standards on Strong Customer Authentication — EBA/RTS/2017/02
- European Banking Authority Opinion on 3DS Exemptions — EBA-OP-2023-01
- Adyen 2023 Payment Experience Report — Key Metrics on 3DS Impact
- Stripe 3D Secure 2 Guide — Migration from 3DS 1.0 to EMV 3DS
- Bank of International Settlements — Retail Payments in Southeast Asia Report 2023
- FIDO Alliance + EMVCo — Joint Whitepaper on Passkeys and SCA (2024)
本文是对 3D Secure 协议的全面梳理，从协议演进、技术架构、集成实践到成功率优化策略。欢迎对本页面提出补充和修订建议。