处理Stripe 3DS结果时怎样区分requires_action和requires_payment_method
看到PaymentIntent落在requires_action，说明发卡行要求持卡人完成验证，Stripe已经把3DS流程推进到需要你展示验证动作的一步。看到它落在requires_payment_method，说明这次没有进入可用的3DS验证流程，常见情形是发卡行不支持3DS或正处在故障中；此时你需要按状态指示重新收集支付方式，但也存在另一种分支：视3DS被触发的原因，Stripe可能获准继续该笔charge的授权步骤，PaymentIntent随之转为processing。两个状态的区别不在"失败与否"，而在于下一步该由谁做什么。
机制：Stripe如何决定进入哪个状态
当一次支付被判定需要3DS验证时，Stripe会联系发卡行的3DS访问控制服务器（ACS），启动3DS流程。收到发卡行返回的流程信息后，Stripe把验证请求提交给发卡行，由发卡行对持卡人进行认证，此时PaymentIntent进入requires_action。在这个状态下，你的集成需要按Stripe给出的动作要求展示验证流程。
如果发卡行完全不支持3DS，或者出现故障，Stripe在规则允许的前提下可能尝试不做验证直接完成支付。对应到状态上：Not supported时PaymentIntent转为requires_payment_method；同时，视3DS被触发的原因，也可能允许继续该笔charge的授权步骤，此时PaymentIntent转为processing。因此requires_payment_method表示"本次没有停在可用的验证流程里"，而不是"这张卡被拒绝了"——卡本身是否可用，不由这个状态直接说明。
状态与下一步动作对照
| PaymentIntent状态 | 含义 | 集成侧该做什么 |
|---|---|---|
requires_action |
发卡行要求验证，Stripe已启动3DS流程并提交认证请求 | 展示所需的3DS验证动作，等待持卡人完成 |
requires_payment_method |
未进入可用的3DS验证流程（如发卡行不支持或故障） | 按状态指示重新收集支付方式后继续 |
processing |
允许继续授权时，未验证分支可能转入此状态 | 按processing处理，等待后续结果 |
需要注意，requires_action并不必然意味着持卡人会看到一个可见的验证页面。发卡行可能请求不同类型的3DS动作，其中有些不会显示可见的挑战，例如无摩擦（frictionless）流程。所以在处理这个状态时，应当以Stripe返回的动作信息为准来渲染，而不是预设一定会弹出验证窗口。
另外，3DS验证所需的数据通常由客户在交易时提供。为减少摩擦和验证失败的可能，Stripe可能用从其他渠道推断的数据来补全这些请求，例如支付流程中从客户处收集的数据、该客户与你过往交易的记录，或从客户卡片、发卡行处可获取的相关信息。这部分属于Stripe侧的处理，不需要你在集成里另行拼装。
一个可复算的判断过程
假设你在服务端创建了一笔PaymentIntent并确认支付，随后轮询或通过webhook拿到状态：
- 状态为
requires_action：读取返回的动作信息，在客户端展示对应的验证流程，等持卡人完成后继续确认，不要在这一步重新创建支付方式。 - 状态为
requires_payment_method：回到收集支付方式的界面，让客户重新提供支付方式后再发起。 - 状态为
processing：说明该笔charge在允许的情况下继续了授权步骤，按processing的常规处理方式等待结果，不要重复发起。
这个判断只需要看状态字段，不需要猜测发卡行的具体行为。至于某一家发卡行为什么不支持3DS、故障持续多久、是否会放行免验证支付，都属于发卡行和Stripe侧的判断，不在你的集成逻辑里推断，也不应据此写死分支。
边界说明
以上只描述PaymentIntent状态与集成动作之间的对应关系。它不构成对任何具体银行行为的预测，也不说明某张卡在某个地区、某个时间点一定会触发哪种流程。实际接入时以Stripe返回的状态和动作信息为准，遇到与本文描述不一致的情况，按接口实际返回处理。