Stripe订阅3D Secure异常：stripe.confirmPayment()提前失败排查

核心原因 #

1. 测试卡固有特性：你使用的4000 0000 0000 3220是Stripe专门用于模拟首次3DS认证自动失败的测试卡。Stripe会在该卡触发的首次支付尝试中，直接标记Payment Intent为「3D Secure attempt failed」——这是测试卡的预设行为，用于模拟真实场景中用户认证失败的情况，和你是否操作弹窗无关。

2. 订阅创建流程配置问题：如果后端创建Subscription时未设置payment_behavior: 'default_incomplete'参数，Stripe会在订阅创建后立即发起自动支付尝试。对于需要3DS认证的卡，这次无用户参与的初始尝试会直接失败（结合测试卡特性），导致Payment Intent提前进入失败状态；你后续调用stripe.confirmPayment()触发的弹窗，实际是发起重试认证流程，但后台已先记录了首次失败的状态。

解决步骤 #

• 调整订阅创建参数：在后端调用stripe.Subscription.create()时，添加payment_behavior: 'default_incomplete'。这会让Stripe将Payment Intent置为requires_action状态，而非立即发起自动支付，等待前端通过confirmPayment()触发3DS认证，避免无用户参与的初始失败。
• 更换测试卡验证正常流程：若要测试完整的3DS认证流程，可使用测试卡4000 0000 0000 3063——该卡会触发正常的3DS挑战弹窗，手动点击「Complete」即可完成认证，Payment Intent会顺利进入成功状态。
• 处理重试逻辑：如果需要模拟认证失败后重试的场景，在前端监听confirmPayment()的错误回调，当捕获到3DS失败的错误时，重新调用confirmPayment()发起第二次认证尝试（使用同一张测试卡的话，第二次尝试可成功完成）。

内容的提问来源于stack exchange，提问作者not_fubar_yet