Stripe 3D Secure：买家验证失败、责任转移和测试卡怎么核对（2026）

摘要：独立站结账弹出 Visa Secure、Mastercard Identity Check 或付款停在需要额外操作时，先核对 3D Secure 这一层：验证失败后支付意图会到哪个状态、成功验证并不保证欺诈责任转到发卡行、沙盒里该用哪些官方测试卡。开户国家和拒付率门槛见前文。依据 Stripe 官方文档，查询日期 2026-11-11。只放官网普通链接（affiliate_later）。

买家在独立站提交银行卡时，页面可能突然跳出 Visa Secure、Mastercard Identity Check 或 American Express SafeKey，也可能付款一直停在「还需要额外操作」，沙盒里却完全看不到验证页。先不要把「付款成功了」理解成「以后这张卡的欺诈拒付一定由银行扛」。先核对这些事：3D Secure（3DS）什么时候会被触发、验证失败后支付意图会到哪个状态、责任转移在官方文档里怎么写、测试时该用哪几张官方测试卡。

开户国家激活后不能改、争议活动和结算币种，已经写在独立站收 Stripe。拒付来了之后怎么准备材料和卡时限，见独立站拒付怎么处理。本文只核对 3DS 这一层。下面事实以 2026-11-11 打开的 Stripe 文档为准，未写明的费率或成功率不要自行补数字。

1. 3DS 是发卡行这一层的额外验证

Stripe 对 3DS 的说明把它写成给银行卡交易增加的一层安全协议：用来核对该次付款的人是不是合法持卡人。启用后，发卡行可能要求持卡人再做一次验证，常见方式是密码、发到手机的一次性验证码，或生物识别。顾客这边往往是通过卡组织品牌来认出这一步。

作为欧洲经济区 PSD2 的一部分，强客户身份验证（SCA）自 2019 年 9 月 14 日起对许多欧洲在线支付生效，可能要求银行卡付款走 3DS 这类双因素验证。官方还写到，英国、印度、日本和澳大利亚的类似法规也可能要求使用 3DS。其他地区可以选用 3DS 来降低欺诈风险。

卡组织已不再支持 3D Secure 1。Stripe 文档要求改用 Payment Intents 和 Setup Intents，以支持 3D Secure 2（3DS2）、Dynamic 3D Secure，并满足欧洲 SCA。文档写明 Stripe 支持的 3DS 协议版本到 2.3.1（含）。

Stripe 会在这些情况下自动触发 3DS：法规强制（例如欧洲的 SCA）、行业指引（例如日本的信用卡安全指引）、发卡行用软拒绝代码要求，或 Stripe 的某些优化条件。你也可以用 Radar 或 API 决定何时提示 3DS。并不是所有交易都支持 3DS，例如部分钱包支付，或顾客不在场、使用以前保存的支付方式完成的 off-session 付款。你不能通过 Stripe API 把 3DS 手动关掉。法规要求的强制验证规则会自动运行，你在 API 里额外请求的 3DS 是叠加上去的。

用 payment_method_options[card][request_three_d_secure] 手动请求时，any 表示希望尽量走无需持卡人再操作的 frictionless 流程，challenge 表示希望走需要持卡人回应的挑战流程。最终由发卡行决定实际流程，Stripe 不能保证你的偏好。结果可以在 Charge 或 SetupAttempt 的 three_d_secure.authentication_flow 里查看。

官方还写明：直接在 Stripe Dashboard 里创建的付款，不会出现 3DS 跳转。要测完整流程，请用你自己集成的前端，或走 API。账户国家是否在支持名单、激活后不能更改，仍先按开户国家核对来看。

2. 验证失败、未出现验证页时，先看支付意图状态

在典型的 Payment Intent 流程里，顾客提交卡信息并确认后，Stripe 会判断这次付款是否支持并且需要 3DS。需要 3DS 时，支付意图可能进入 requires_action，由发卡行的 3DS 访问控制服务器开始验证。发卡行也可能走看不见挑战页的 frictionless 流程，所以「没弹窗」并不等于「没做 3DS」。

验证结果会把流程带到不同状态，文档写明的常见情况包括：

验证通过：Stripe 尝试扣款，支付意图进入 processing。
验证失败：支付意图进入 requires_payment_method，需要换一种支付方式，或再次确认以重试 3DS。
在允许的边缘情况下，结果为 attempt_acknowledged 时仍可能继续扣款，支付意图进入 processing。印度电子授权（e-mandate）用于经常性付款时例外：除 authenticated 以外的结果都按失败处理。

最终付款结果可能是 succeeded、requires_capture 或 requires_payment_method。要查看这张卡付款有没有尝试 3DS，阅读 Charge 里 payment_method_details.card.three_d_secure。Stripe 会在顾客尝试验证时填充该字段，three_d_secure.result 表示验证结果。

卡不支持 3DS，或验证过程出错时，付款在允许的情况下可能按普通授权继续。此时一般不会把欺诈责任转到发卡行，因为并没有一次成功的 3DS 验证。发卡行的 3DS 服务中断、卡未注册 3DS、查找请求失败，都会走到不同结果，不要只用「页面没跳转」来判断。

集成侧还要注意：网页上的 3DS 界面由发卡行控制字体和颜色，不能改成和站点一模一样。若网站有内容安全策略，文档要求允许来自 https://js.stripe.com、https://hooks.stripe.com 以及你传入的 return_url 来源的 iframe。不要给 3DS 的 iframe 加 sandbox 属性，部分发卡行实现会因此失败，付款无法完成。iOS 和 Android 上自定义 3DS 界面时，超时时间必须至少 5 分钟，其中包含网络往返和等待顾客输入。

3. 成功完成 3DS，也不等于责任一定转移

Authenticate with 3D Secure 在「争议和责任转移」一节写得很直接：成功的 3DS 验证并不保证责任转移。对后来发生、且符合条件的欺诈争议，通常可以预期责任转移到发卡行，但任何一笔具体付款或争议都不能保证。官方还要求：不要把成功付款、成功的 3DS，或电子商务指示码（ECI）说成绝对保证；charge.succeeded 只确认付款成功，payment_method_details.card.three_d_secure.result 为 authenticated 只确认 3DS 验证成功；ECI 可帮助判断是否符合条件，但不能保证责任转移。最终结果由卡组织规则以及该笔付款和争议的具体条件决定。

常见还需要单独核对的情况包括：

卡不支持 3DS，或验证过程出错后付款仍完成：一般不会把责任转到发卡行。
你可能仍会收到早期欺诈警告（Early Fraud Warning），即使责任转移规则覆盖了该笔付款，也仍可能收到一小部分被标成欺诈的争议。
对已经完成 3DS 验证的付款，你仍可能收到争议询证（inquiry）。这还不是扣回款项的拒付，只是要求提供信息。你必须回复。若不回复，持卡人银行可能发起因未回复而产生的资金拒付（no-reply chargeback），并可能让责任转移失效。回复时要说明订了什么、如何交付、交给了谁（实物、电子商品或服务都要写清）。
顾客以「没收到货」等其他理由提出争议时，走标准争议流程，见拒付处理前文。
银行批准 SCA 豁免时，官方豁免说明写明：对欺诈交易的责任转移不适用。Data Only（仅数据）流程也不会产生责任转移。
文档举例：账户欺诈水平过高并进入监控计划时，即使 3DS 验证成功，也可能不适用责任转移。部分行业会被卡组织排除，例如 Visa 不对电汇或汇票、提供外币或非法定货币的非金融机构、储值卡购买或充值等业务提供责任转移。这些是例子，不是完整清单。
责任转移也可能在授权之后被降级，或卡组织的争议拦截没有抓住该笔交易的责任转移。若你选择抗辩，Stripe 会自动把请求到的 ECI 和 3DS 验证结果加入证据，官方仍建议你补充其他细节。

Apple Pay 或 Google Pay 等带有等效密码（cryptogram）的付款，在部分情况下也可能适用责任转移，具体仍以卡组织规则和该笔争议为准。

4. 沙盒里用官方测试卡核对

在沙盒中使用测试 API 密钥时，可用 Stripe 官方测试卡触发 3DS 挑战流程，CVC、邮编和未来到期日可以任意填写。验证过程会显示模拟验证页：选择授权相当于验证成功并回到你设置的返回地址；选择 Failure 相当于验证失败。下面几张卡摘自同一篇验证流程文档的测试表，以该页当前内容为准：

卡号	3DS 情况	文档说明
4000 0000 0000 3220	必须完成	必须完成 3DS2，付款才能成功。默认 Radar 规则会为这张卡请求 3DS。
4000 0025 0000 3155	必须完成	off-session 付款需要 3DS2，除非你已为未来付款完成设置；设置之后，off-session 不再要求验证。
4000 0084 0000 1629	必须完成，随后拒绝	必须完成 3DS，但验证后付款会以 `card_declined` 失败。默认 Radar 规则会请求 3DS。
4000 0000 0000 3055	支持但非必须	仍可以做 3DS，但并非必须。默认 Radar 规则不会为这张卡请求 3DS。
4242 4242 4242 4242	支持但未注册	支持 3DS，但未注册。即使 Radar 请求 3DS，顾客也不会再走额外验证。默认 Radar 规则不会请求 3DS。
3782 822463 10005	不支持	不支持 3DS，也无法调用。支付意图会在不做验证的情况下继续。

更多卡号和 PaymentMethod 标识见 Stripe 测试文档。其他多数 Visa 和 Mastercard 测试卡，不会要求发卡行再做一次持卡人验证。直接在 Dashboard 里造一笔付款，看不到 3DS 跳转，这是文档写明的限制，不能用来判断集成失败。

上线前可以按这几项核对：沙盒里用「必须完成」的测试卡，能否看到模拟验证页并分别走通授权与失败；失败后支付意图是否回到 requires_payment_method；真实付款里 three_d_secure.result 和 ECI 记在哪；争议询证的通知和截止日期在 Dashboard 的哪一页。不要把测试卡用到正式环境。

风险与范围

本文面向已经在 Stripe 支持地区持有账户、并在独立站接入银行卡收款的读者，只整理官方文档里关于 3DS、责任转移和测试卡的核对项。能否开户取决于企业注册地和银行所在地是否在当前支持名单，见账户国家前文。本文不构成开户、外汇、支付集成或法律意见，也不保证某笔付款一定获得责任转移。大陆读者如涉及跨境收款和结汇，还需遵守所在地外汇与税务规定，不要用第三方「镜像」或绕开官方账户国家限制的做法。

3DS 可能增加结账摩擦，部分顾客会在验证页离开。成功率变化以 Dashboard 里的支付分析为准，本文不编具体比例。有 Radar Plus 时，可以用自定义规则进一步控制何时请求 3DS，以及如何处理不同验证结果；SCA 强制规则仍会独立运行。