钱包付款或off-session扣款没弹3DS时怎么判断
没弹3DS，不等于验证环节漏了。按Stripe文档的说法，并非所有交易都支持3DS，钱包（wallets）和off-session付款就是它举的两个例子。当一笔交易不支持3DS时，PaymentIntent可能转为 requires_payment_method 状态；但文档同时说明，视触发3DS的原因，边缘情况下也可能允许继续授权。所以遇到钱包付款或off-session扣款没有出现验证页面，第一件该做的事是确认这笔交易本身是否在3DS支持范围内，再看PaymentIntent落在哪个状态，而不是先怀疑集成出了问题。
先分清“不需要”和“不支持”
文档在描述触发3DS的典型Payment Intent流程时，把结果分成几种情形，判断时可以对号入座：
- 不需要：例如因为适用豁免（exemption），Stripe直接尝试扣款，PaymentIntent进入
processing状态。这种情况下没有验证页面是正常的。 - 发卡行以soft decline要求验证：Stripe会自动重试，并按“需要3DS”继续处理。
- 不支持：文档给出的分支是PaymentIntent转入
requires_payment_method，同时注明视触发3DS的原因，某些边缘情况可能允许继续授权。钱包和off-session付款被文档列为不支持3DS的例子。
关键区别在于：前两种是“支持3DS但这次没触发或自动续走”，第三种是“这条路径本身就不在3DS支持范围内”。看到没有验证页面时，先看PaymentIntent落在哪个状态，比凭界面表现猜测更可靠；但也不能把 requires_payment_method 当成不支持时的唯一结果，文档保留的继续授权情形需要一并考虑。
用状态和触发来源定位问题
3DS是否被评估，取决于监管要求、Radar规则、手动API请求、发卡行soft decline等条件。也就是说，一笔交易没弹验证，可能是没满足触发条件，也可能是根本不支持。判断时可按这个顺序：
- 查PaymentIntent当前状态。若停在
requires_payment_method且原因指向3DS不被支持，属于文档所说的“不支持”情形；但应同时核对是否落入文档提到的边缘可继续授权情况，不宜仅凭状态名下结论。 - 确认支付方式类型。如果走的是钱包或off-session扣款，本身就落在文档明确举出的不支持例子里，没有验证页面符合预期。
- 如果状态是
processing，说明Stripe已按不需要验证处理（可能因豁免），属于正常路径。
需要强调的是，文档只把“钱包”作为一个整体例子，并没有逐一说明各类钱包产品的具体规则。因此不能把这句结论外推到所有钱包场景，也不宜据此推断某个具体钱包一定不走3DS。判断依据应落在具体交易的支付方式与PaymentIntent状态上。
一个可复算的核对思路
假设某笔off-session扣款提交后，PaymentIntent显示 requires_payment_method，且返回原因指向3DS不被支持（此处假设为核对演示，不对应任何具体账户的实际返回）。按文档口径，这属于“不支持”分支：交易通常没有进入验证，也不会因为重试就自动产生3DS流程。不过文档保留了视触发原因允许继续授权的边缘情形，所以处理时应先确认返回原因与状态是否一致，再决定是改用支持3DS的支付路径、按业务规则另行处理，还是排查是否属于可继续授权的情况，而不是反复重发同一笔请求期待弹出验证。这个例子只用于说明状态与分支的对应关系，不构成对任何具体账户或费率场景的结论。
边界提醒
文档同时说明，即使交易触发了3DS，发卡行也可能要求客户完成验证，前提是这张卡支持3DS；验证要求来自发卡行，Stripe只是发起请求。反过来，没触发验证也不代表交易一定成功，二者是不同的判断维度。本文只讨论“为什么没弹3DS”这一机制问题，不涉及具体风控策略的取舍。