3DS验证通过后：付款状态为什么先到processing
在确认PaymentIntent时触发3DS验证，验证结果会直接决定PaymentIntent接下来停在哪个状态。验证通过（Authenticated）后，Stripe会尝试发起扣款，PaymentIntent随即转入processing；验证失败则转入requires_payment_method，意味着需要更换支付方式，或者重新确认PaymentIntent再次走一遍3DS流程。因此，看到3DS验证成功却只拿到processing，是正常的状态流转，并不代表扣款已经最终成功。
核对一次3DS验证后的状态流转
假设你正在对接卡支付的3DS验证，用户在验证页面完成了身份验证，前端回调显示认证成功。此时你需要回答的问题是：PaymentIntent现在应该是什么状态，下一步该做什么。
先看确认动作本身。触发3DS验证时，认证请求是在确认PaymentIntent的过程中发起的。如果3DS流程顺利走完，PaymentIntent可以直接转入processing；如果还需要补充步骤或数据才能完成3DS流程，则会先停在requires_action，等待后续动作。也就是说，requires_action是流程尚未走完的中间态，processing才是验证通过并已尝试扣款后的状态。
再看认证结果的分支：
- Authenticated（已认证）：Stripe尝试扣款，PaymentIntent转为
processing。 - Failure（失败）：PaymentIntent转为
requires_payment_method，此时需要换一种支付方式，或者重新确认PaymentIntent以重试3DS。 - 其他情形：视触发3DS的具体原因，个别边缘情况下允许继续授权。例如结果为
attempt_acknowledged时会发起扣款，PaymentIntent同样转为processing。一个例外是印度 recurring payments 的 e-mandates：除已认证外的任何结果都按失败处理。
这里要特别注意范围。processing只说明扣款已被尝试、正在处理中，不能据此推断何时会变成succeeded。PaymentIntent最终会落到succeeded、requires_capture或requires_payment_method之一，取决于支付结果，但本流程说明没有给出processing到这些终态的时间预期。核对状态时不要把processing当成成功，也不要把“验证通过”和“扣款完成”画等号。
如何事后核对3DS是否被尝试
如果需要在事后确认某笔卡支付是否支持并尝试过3DS，可以读取Charge的payment_method_details中卡信息的three_d_secure属性。客户尝试对卡片进行认证时，Stripe会填充该属性，其中的three_d_secure.result表示认证结果。这个字段适合用来对账或排查，而不是用来预测状态流转的时间。
核对时的操作要点
第一，以PaymentIntent的当前状态为准，不要用前端“验证成功”的提示替代服务端状态。第二，遇到requires_payment_method时，按失败处理：更换支付方式，或重新确认PaymentIntent重试3DS。第三，遇到requires_action时，说明3DS流程还缺步骤或数据，应先补齐再判断结果。第四，处于processing时保持等待并监听后续状态变化，不要重复发起扣款，也不要对外宣称支付已完成。
以上限定适用于Stripe文档所述的3DS认证流程，不涉及具体地区费率、账户资格或版本差异；若你的集成涉及印度 recurring e-mandates，需按上述例外单独判断。