Stripe保存卡供下次结账展示：为什么需要单独勾选同意
保存一张卡和以后能不能直接拿这张卡扣款，是两件授权要求不同的事。按 Stripe 文档对 SetupIntent 的说明，如果保存支付方式是为了未来的 on-session 使用——比如在之后的结账页面上把这张卡展示给客户选择——你必须就这一具体用途显式收集客户同意，例如提供一个“保存我的支付方式供未来使用”的勾选框。如果保存是为了未来的 off-session 扣款，也就是客户不在网站或应用上操作时由你发起扣款，则需要事先取得许可，建立协议（有时称为 mandate），让客户选择加入，并在条款中写明你计划如何处理付款。两项要求分别针对不同用途，不能互相替代：一个勾选框解决的是“能不能再展示”，一份协议解决的是“能不能在客户不在场时扣款”。
用一个任务看清两条路径
假设你在做结账页，客户这次输入卡号完成支付，你希望下次他来结账时这张卡已经出现在列表里，他点一下就能用。这个任务属于 future on-session use。文档的要求很直接：为这一特定用途显式收集同意。落地方式就是在结账页放一个勾选框，文案说明这张卡会被保存供未来结账使用，客户勾选后才保存。这个同意是针对“未来展示”这一用途收集的，不能用一句笼统的“同意服务条款”代替；至于勾选框的默认状态，文档未作规定，应结合适用的法律、法规和卡组织规则判断。
同一张卡，如果你还想在客户不访问网站的时候发起扣款，比如按周期续费或在约定时间扣款，那就是 future off-session use。这条路径需要的不是勾选框，而是前置的协议：在网站或应用中加入条款，说明你计划如何处理付款，并让客户选择加入。文档给出的最低覆盖范围包括三项——客户授权你代其发起一笔或一系列付款、付款的预期频率（一次性还是周期性）、付款金额如何确定。对受 SCA 影响的用户，这份协议还有助于付款不中断地完成。
两条路径可以在同一个结账流程里并存，但各自的授权要分别落实。客户勾选“保存供下次使用”，支持的是你下次把卡展示给他；你要在他不在场时扣款，还得有覆盖上述内容的协议。两项要求分别对应不同用途，一项的落实不当然覆盖另一项。文档还提到一个区分手段：如果既要保存仅用于离线场景的支付方式，又要保存可以展示给客户用于未来 on-session 购买的支付方式，可以使用 PaymentMethod 对象上的 allow_redisplay 参数来区分。资料只说明该参数可用于区分这两类支付方式，未说明它可以替代收集同意。
勾选框为什么必须单独存在
把“保存卡”做成一个独立、明确、针对具体用途的同意动作，原因是它对应的后续行为不同。on-session 展示发生在客户下一次主动结账时，客户仍在场，最终是否使用由他决定；但“把卡存下来”这个动作本身已经改变了他下次结账时看到的内容，所以文档要求就这一用途显式征得同意。off-session 扣款则发生在客户不在场时，风险重心从“展示”移到“代为发起付款”，因此要求的是写明授权范围、频率和金额确定方式的协议，而不是一个勾选框。
这也是为什么不能把两种同意合并成一句含糊的话。勾选框的文案应当指向“供未来结账使用”这一具体用途；协议条款应当覆盖代扣的授权、频率与金额规则。文档没有给出统一的文案模板或适用所有地区的结论，这些要结合你所在的地区、适用的法律、法规和卡组织规则来判断。本文只说明机制层面的区分，不构成法律意见。
实施时的检查点
在结账页保存卡之前，先问清这张卡之后会被怎样使用。只用于下次结账展示，就在页面上显式收集针对该用途的同意，并考虑用 allow_redisplay 区分仅离线使用与可展示的支付方式。需要 off-session 扣款，就在网站或应用中提供覆盖授权、频率和金额确定方式的条款并让客户选择加入。两种用途都有，就分别落实，不要把其中一个当成另一个的替代。