Stripe SetupIntent保存卡但不扣款：和直接付款差在哪
SetupIntent 和 PaymentIntent 的核心差别在于目标不同：PaymentIntent 的目标是完成一笔扣款，SetupIntent 的目标是把付款凭证保存下来、配置成未来可直接扣款的状态，该操作本身不创建扣款。设置银行卡时，可能需要认证客户或向发卡行检查卡的有效性，Stripe 会在整个过程中持续更新 SetupIntent 对象的状态。
用租车场景理解两者的分工
按 Stripe 文档给出的例子，租车公司在客户租车前先收集付款方式，租期结束后再扣款。这个流程里有两个不同动作。
第一个动作是“存卡”。客户在租车前输入卡信息，平台通过 SetupIntent 完成付款方式的设置。设置银行卡时，可能需要认证客户，也可能需要向发卡行检查卡的有效性。流程结束后，付款方式被保存并配置为可供未来付款使用。文档对此的表述是：它“similar to a payment, but no charge is created”——类似一次付款，但不产生扣款。
第二个动作是“扣款”。租期结束、需要实际收款时，平台使用已保存的付款方式发起支付，这时才产生真实的资金流动。存卡成功与后续扣款成功是两次独立的交互，前者完成不保证后者一定成功；扣款能否完成还取决于发卡行的授权结果。
所以在这个任务里，SetupIntent 负责把付款凭证备好，实际扣款则发生在后续使用该凭证发起支付的时候。把两者混为一谈的常见后果是：以为存卡就等于收了钱，或者以为扣款失败是因为卡没存好。
保存凭证为什么需要单独的流程
直接付款时，验证与扣款在同一次交互中完成，用户当场授权，流程自然闭环。而“先存后用”的场景里，扣款发生在未来某个时点，平台需要在那之前确认这张卡有效且经过持卡人授权。SetupIntent 就是承载这一确认过程的容器，Stripe 会在过程中持续更新其状态，记录验证进展和付款方式是否已正确配置。
文档强调的目标是让付款凭证“configured correctly for any scenario”，即保存下来的付款方式要能应对后续的付款场景，而不只是看起来存进去了。对银行卡而言，这可能意味着认证客户身份，也可能意味着向发卡行查询卡的有效性。
文档给出的三类典型场景
原始文档举了三个例子，都围绕“先收集、后扣款”这一共同结构：
租车公司在客户租车前收集付款方式，租期结束后再扣款；众筹网站收集卡信息，仅在活动达到特定金额时才扣款；公用事业公司按用量每月扣费、金额每月不同，但在第一个月付款前就要收集 SEPA 付款细节。
这三个例子的共同点是扣款时点或金额在收集凭证时并不确定，因此不适合在下单时直接完成扣款。需要注意，这些只是文档用来说明适用场景的例子，不构成对任何具体行业合规要求的说明；不同行业的扣款时点、授权方式和信息披露规则另有监管要求，不能从 SetupIntent 的机制推导出来。
存卡不一定单独走一遍
文档还提到，在实际扣款的 Checkout 流程中，也可以顺带把付款方式设置为未来可用。也就是说，存卡并非只能通过独立的 SetupIntent 完成。规划支付流程时值得先想清楚：如果首次扣款就在眼前，未必需要单独走一遍 SetupIntent；如果扣款要等到未来某个不确定时点，独立设置付款方式才更贴合需求。