先把设置、许可和实际付款分开
来源事实：Stripe 的 Setup Intents API 用于为未来支付设置付款方式，设置本身不会创建扣款。[2] 设置银行卡时，可能需要客户完成认证，或由发卡银行检查卡片是否有效。[2] 编辑建议：在业务记录中分别回答三个问题：客户是否同意预定用途，付款方式设置是否完成，以及后来那笔支付是否真正成功。不要让一个“已保存”的标签同时代表这三种结论。以租赁业务为例，可以在服务开始前收集银行卡，服务结束后再收款，但内部仍应把资料设置与款项收取分别记录。向客户展示设置完成时，也应说明完成的是哪一步，避免把尚未发生的收费说成已经支付。本文讨论的是 Stripe 的保存同意与认证恢复，不是 PayIn 功能说明，也不讨论 SCA 豁免资格或欺诈责任转移。
明确客户究竟允许哪一种未来使用
来源事实：Stripe 要求对未来 on-session 使用取得明确同意，例如在客户下一次结账时展示已保存的付款方式。[2] 未来 off-session 使用同样需要许可；预先建立协议，有时称为 mandate，才能在客户未主动使用网站或应用时向其扣款。[2] 编辑建议：分别解释“下次由客户选择这张卡付款”和“将来由商户按约定发起扣款”，不要把两者写成含糊的一句话。客户选择保存卡片以便结账，不应被内部流程自动解释为同意任何未来费用。在制作复选框之前，先写清谁发起交易、客户是否在场、费用对应什么购买或义务，再据此检查同意文案。若同一个界面包含两种用途，应让用户能够理解各自含义，并让后台记录保留这些区别，而不是仅保存一个无法解释用途的布尔值。
把未来扣款条件写到可以逐项核对
来源事实：Stripe 要求在网站或应用中加入说明支付处理方式的条款，并让客户主动选择同意。[2] 条款至少应涵盖商户代表客户发起一笔或一系列支付的许可、预计扣款频率，以及付款金额的确定方式。[2] 编辑建议：明确是一次性还是持续性收费，并用普通语言说明金额怎样计算。对于按使用量计费的服务，可以在审阅文案时询问：统计什么用量，采用哪一档价格，客户在哪里能够理解这套计算逻辑？这些是编辑提供的起草问题，不是 Stripe 审核通过的法律模板。内部证据记录可保留客户标识、接受时间、当时的条款版本与覆盖的用途。未来收费安排发生变化时，指定负责人重新评估原有约定是否适用，不要仅因卡片仍然保存在系统中，就悄悄扩大当初许可的范围。
让 usage 配置对应真实的付款场景
来源事实：SetupIntent 的 usage 参数向 Stripe 表明日后如何使用付款信息；仅用于客户在场付款时，文档建议使用 on_session，离线付款或同时包含两类用途时则使用 off_session。[2] 未指定时，usage 默认为 off_session。[2] Stripe 说明，为离线使用准备银行卡可能在设置阶段引入认证，从而减少后续需要客户介入的情况，但 usage 本质上仍是一项优化。[2] 编辑建议：显式记录预定配置，并把它与客户接受的用途进行对照。默认参数不能作为客户已经授权的证据，技术人员也不应通过选择一个字段值替代同意流程。准备好说明设置阶段可能出现认证的客服文案，并在复核中分别确认两件事：技术上是否按目标场景准备付款方式，以及业务上这笔未来费用是否确实落在客户许可的范围内。
扣款许可与再次展示卡片的许可分别检查
来源事实：Stripe 指出，可以通过 PaymentMethod 对象的 allow_redisplay 参数，区分仅为离线用途保存的付款方式与可以在未来客户在场购买时展示的付款方式。[2] 文档同时要求对未来 on-session 使用取得明确同意。[2] 编辑建议：将已保存卡片的展示规则与未来收费规则分别审查。为某项服务结束后的费用收集了一张卡，不应仅因系统持有其标识，就自动在所有结账入口中把它列为可选方式。梳理付款方式会出现在哪些页面、这些展示对应何种同意，以及不同用途之间是否存在意外的继承关系。本文引用的概述页没有提供 allow_redisplay 的完整实现规范，因此上线前仍需核对实际集成的字段用法；不能仅根据概述就声称某个具体字段值已经完整执行了所有展示限制。
把重新认证设计为明确的客户返回流程
来源事实：Stripe 提醒，无论银行卡最初按 on-session 还是 off-session 用途设置，未来支付仍可能需要认证。[2] 当离线银行卡付款需要认证时，文档要求把客户带回线上完成支付。[2] 编辑建议：将这条返回路径作为产品需求，而不是等到收费受阻后才临时让客服处理。向客户说明哪笔付款需要操作，引导其进入经过身份验证的账户页面，再完成所需付款流程。不要让客户通过客服聊天或邮件提交卡号、认证验证码等信息。恢复过程中应始终能识别对应的付款义务，并在显示下一步操作之前检查当前付款状态，避免对已经解决的事项继续发出不恰当指引。通知已发送、客户已点击和认证已开始，都不应被记录成付款成功；仍需客户行动的情形，应如实呈现为待处理状态。
上线前走完从同意到恢复的完整审查
来源事实：Stripe 将保存客户付款资料时遵守适用法律、法规与卡组织规则的责任归于商户。[2] Setup Intents 指南还要求在应用中建立恢复流程，因为前期设置不能排除所有未来认证要求。[2] 编辑建议：由产品、工程以及适当的法律顾问共同检查一个完整场景：客户实际看到的条款、接受记录、预定 usage、允许展示卡片的位置，以及需要认证时如何返回。再加入两个分支：客户中途放弃认证，以及收费安排发生变化。为仍待客户操作的事项指定责任人，并避免向业务团队承诺保存成功就一定能收款。这些是拟议的验收检查，不是已经执行的支付测试，也不构成法律充分性评估。本文核验日期为 2026-09-20；原始来源未注明发布日期，不能将核验日期解释为该功能上线或规则开始生效的时间。
来源与日期
本次核验日期：2026-09-20。来源日期按原页面明确标注的发布或更新时间分别列示；未标注不等于本日发布。本文为公开文档研究，未进行真实支付、安全审计或辅助技术合规认证。厂商事实仅归属于被引用厂商；流程建议为编辑综合。