Stripe 的 Customer、PaymentMethod、SetupIntent、setup_future_usage、Mandate、on-session、off-session 和 allow_redisplay 有什么区别？
跨境电商和外贸服务常需要“今天保存付款方式，以后按订单、账期或订阅扣款”。Stripe 中与这个流程相关的对象和参数很多：Customer 保存客户身份，PaymentMethod 表示付款凭证，SetupIntent 引导无首笔收款的设置流程，setup_ 在当前付款中为未来复用做准备，Mandate 记录授权，而 on_session、off_session 与 allow_redisplay 又分别描述使用场景和展示权限。
本文目录（38 节）
一句话结论
Customer 是业务客户容器；PaymentMethod 是可用于支付的凭证对象；SetupIntent 在不立即收费时完成凭证设置；PaymentIntent 的 setup_ 在本次收款同时优化未来复用；Mandate 是特定付款方式所需的扣款授权记录；on_session 与 off_session 描述客户是否在场；allow_redisplay 管理已保存方式能否再次展示。它们互相协作，不能彼此替代。
Customer 管什么
Customer 用于关联客户身份、联系方式、默认支付配置、发票和多个 PaymentMethod。它不是银行卡本身，也不代表客户已经授权任意未来扣款。业务数据库应保存 Stripe Customer ID 与内部用户ID的映射，并在服务端校验归属关系。
PaymentMethod 管什么
PaymentMethod 封装卡、银行借记或其他付款方式的可复用支付信息及类型详情。服务端通常只保存其 pm_ ID，而不接触原始卡号。PaymentMethod 被创建或附加到 Customer，并不自动证明它已经针对未来场景完成认证和授权优化。
SetupIntent 管什么
SetupIntent 用于设置并保存未来使用的付款方式，但不创建一笔收费。它会追踪收集、确认、额外认证、处理中、成功或失败等状态。租赁押后结算、按用量月结和先开户后收费等场景通常适用。
setup_future_usage 管什么
当客户当前就要付款，同时希望以后复用该方式，可以在 PaymentIntent 或相应托管流程中声明 setup_。Stripe 会利用本次支付完成必要设置并标注未来使用意图。它不是一个独立对象，也不能替代客户同意。
两种保存路径如何选择
“现在不收费，只保存”通常用 SetupIntent；“现在收费，并保存本次方式”通常用 PaymentIntent 加 setup_，或使用 Checkout 对应配置。选择应由真实交易时点决定，不要为了少一次接口请求而制造零金额或虚假付款。
Mandate 是什么
Mandate 表示客户授权商户发起一笔或一系列付款的协议记录，尤其常见于银行借记和未来离线支付。不同付款方式、国家和网络规则对授权文本、通知和撤销要求不同。Mandate对象的存在不免除商户遵守法律和网络规则的责任。
Mandate 与 PaymentMethod 的区别
PaymentMethod回答“用什么凭证付款”，Mandate回答“基于什么授权扣款”。一个付款方式可能关联授权信息，但不能把 pm_ ID 当作客户同意的证据。审计中应保留同意时间、条款版本、用途、频率和金额决定方式等业务证据。
on-session 是什么
on-session 表示付款发生时客户正在网站或应用中，可及时完成3D Secure、重定向或其他认证。保存的方式若只计划在客户结账时再次展示和使用，可以按 on-session 意图设置，以减少不必要的前置摩擦。
off-session 是什么
off-session 表示商户尝试扣款时客户不在交互流程中，无法立即响应认证挑战。订阅续费、账期扣款和服务完成后收费是典型场景。创建未来付款时需要明确标记 off-session，并准备在银行要求认证时召回客户。
usage 与实际扣款参数不是一回事
SetupIntent 的 usage 描述计划如何在未来使用凭证，是设置阶段的优化信号；后续 PaymentIntent 的 off_session=true 则描述这一次支付尝试的实际环境。设置过 usage=off_session 不等于以后创建付款时可以省略正确参数。
为什么 off-session 仍可能失败
正确设置只能提高成功率，不能保证免认证。银行可能基于风险、金额、地区或监管要求请求客户重新认证，也可能拒绝交易。系统必须把“需要客户操作”视为正常业务分支，而不是无限自动重试。
allow_redisplay 管什么
allow_redisplay 用于区分已保存付款方式是否可以在未来界面再次向客户展示。保存用于后台离线扣款的凭证，不一定获得了未来结账页展示授权。展示权限与技术可扣款能力是两个维度。
allow_redisplay 与 consent 的关系
该字段帮助应用表达和执行展示策略，但不能替代清晰、可证明的客户同意。界面应说明保存目的、未来使用方式，并根据适用规则让客户主动选择。条款和参数需要一致，不能前端说“仅本次”而后端静默复用。
Attachment 表示什么
把 PaymentMethod attach 到 Customer，意味着凭证归入该客户容器，便于后续列出和使用。若成功的 SetupIntent在创建时已指定 Customer，Stripe可自动附加产生的 PaymentMethod。不要在 webhook 与同步返回两条路径中重复附加而造成竞态。
为什么不建议只调用 attach 保存卡
单纯附加 PaymentMethod可能绕过针对未来使用的设置与认证优化。Stripe官方建议使用 SetupIntent，或在当前付款中使用 setup_。这样能更好地适应强客户认证和区域规则，降低未来扣款受阻概率。
默认付款方式是什么
Customer下可以有多个PaymentMethod，而订阅或发票还可能有各自默认方式。附加不等于设为默认，设为默认也不代表其他方式被删除。读取时要明确对象层级和优先级，避免账单使用了非预期凭证。
SetupIntent 的主要状态
常见状态包括 requires_、requires_、requires_action、processing、succeeded 和 canceled。只有看到终态并结合付款方式类型，才能进入后续业务步骤。不要把前端确认函数返回当作最终成功证据。
requires_action 如何处理
该状态说明客户需要完成认证或重定向。on-session流程可以立即引导客户；异步方式则可能等待外部处理。前端应使用Stripe提供的客户端流程，不应收集或转发敏感凭证到自有服务器。
processing 为什么不能立即扣款
部分银行支付方式的设置可能需要数日。processing 不是失败，也不是成功。应用应显示“处理中”，通过 webhook推进状态，并为重复通知实现幂等，而不是轮询后强行创建收费。
succeeded 是否保证未来付款成功
不保证。它表示设置流程成功且凭证已为计划场景做了优化，但后续付款仍受余额、卡状态、风控、认证和网络影响。业务文案不应承诺“以后一定自动扣款成功”。
Checkout setup mode 是什么
如果使用Stripe托管Checkout，可通过setup模式只保存付款方式而不收费。完成后由Checkout Session关联SetupIntent，再从成功对象取得PaymentMethod。它是SetupIntent的托管入口，不是另一种授权模型。
Checkout payment mode 如何保存
当前付款同时保存时，可使用Checkout支持的未来使用配置，并关联现有或新建Customer。具体支持取决于付款方式和模式。不要假设所有Dashboard启用的方法都支持setup mode或off-session复用，应查官方支持表。
Payment Element 与动态付款方式
Payment Element可根据币种、国家、金额与配置显示合适方式，但每种方式对SetupIntent、未来使用、手动扣款和重定向的支持不同。上线前应按真实国家与币种逐项测试，而不是只用测试卡验证界面出现。
单次方式与可复用方式
有些支付方式天然需要每次客户参与，或只在特定产品流程中支持复用。看到PaymentMethod对象不代表该类型可无限复用。应以Stripe当前payment method support表和账户区域能力为准。
客户同意至少包含什么
对于未来off-session付款，条款通常应说明客户授权商户发起付款、预计频率、一次性或重复性，以及金额如何确定。具体法律文本应由合规人员审核；技术团队需保存条款版本和同意证据，并提供撤销路径。
外贸订单的推荐建模
内部订单保存Customer ID、选用的PaymentMethod ID、授权用途、币种和结算规则；Stripe对象ID只作支付引用。报价、订单、发票与支付尝试应分别建模，不能用一个PaymentIntent长期覆盖多个独立订单。
后续 off-session 扣款流程
服务端使用正确Customer和PaymentMethod创建新的PaymentIntent，设置金额、币种、off_session=true并确认。请求要使用幂等键。成功、失败和需要认证均通过PaymentIntent状态与webhook驱动本地状态机。
需要认证时如何恢复
不要不断后台重试。通知客户返回安全的支付页面，建立新的on-session恢复流程，让其完成认证或选择另一方式。恢复链接应短时有效并绑定订单和客户，不能把client secret写入公开日志或邮件正文。
Webhook 为什么是最终依据
浏览器可能关闭、网络可能中断，异步付款也可能晚于页面返回。服务端应验证Stripe签名，以事件对象状态更新订单，并按Event ID或业务键幂等处理。同步响应适合即时反馈，但不能替代webhook闭环。
常见错误一：只保存 pm_ID
数据库里有 pm_ ID并不证明它属于当前Customer、经过未来使用设置或获得合规授权。每次使用前应验证对象归属、类型和业务授权，不能接受客户端任意提交的PaymentMethod ID进行扣款。
常见错误二：把 attach 当同意
attach是API关系变化，不是法律同意。未经明确说明就保存或展示付款方式，可能违反网络规则和隐私要求。技术日志、界面记录和条款版本应共同构成可审计链路。
常见错误三：混用测试与正式对象
测试模式的Customer、PaymentMethod、SetupIntent和Mandate不能直接用于正式模式。部署时还要校验API Key模式、webhook endpoint和对象前缀对应的环境，避免测试成功后正式环境找不到资源。
上线测试矩阵
覆盖成功保存、客户取消、3DS认证、银行异步处理、off-session成功、需要认证、余额不足、过期卡、换卡、撤销同意、重复webhook、网络超时和幂等重放。按主要国家、币种与付款方式分别验证。
监控指标
分别统计SetupIntent各状态、保存成功率、off-session授权率、后续扣款成功率、需要客户操作率、恢复完成率和按付款方式的失败码。不要只看“接口200”，也不要在日志中保存client secret、完整账单信息或敏感支付数据。
FAQ
1. Customer里有PaymentMethod就能自动扣款吗？
不能据此保证。还需要适当的设置流程、客户授权、付款方式支持，以及每次PaymentIntent的正确参数。
2. SetupIntent会产生一笔零金额Charge吗？
不会。它用于设置付款凭证而不创建收费；银行侧可能有验证行为，但不应把它建模成普通订单付款。
3. 当前已经收款，还需要SetupIntent吗？
若要保存本次方式，通常可在当前PaymentIntent中使用setup_，无需再创建重复SetupIntent。
4. usage=off_session 就保证以后免3DS吗？
不保证。它帮助正确优化和标记场景，银行仍可能要求客户认证。
5. Mandate和客户勾选框是同一个东西吗？
不是。勾选框是收集同意的界面证据之一，Mandate是支付体系中的授权记录；还需保存条款和审计信息。
6. allow_redisplay=never 是否等于不能后台扣款？
不应直接等同。它主要涉及再次展示许可，实际扣款能力和授权需按PaymentMethod、Mandate与设置流程判断。
7. SetupIntent succeeded后何时更新订单？
SetupIntent只代表付款方式设置成功，不代表订单已付款。订单付款应由后续PaymentIntent或Invoice状态更新。
8. 客户删除付款方式后还能继续使用旧ID吗？
不应。应用需同步解绑或失效状态，停止新扣款并按业务规则要求客户提供新的授权方式。
Stripe官方资料
- https:
/ / docs. stripe. com/ payments/ setup- intents - https:
/ / docs. stripe. com/ payments/ paymentintents/ lifecycle - https:
/ / docs. stripe. com/ payments/ save- and- reuse - https:
/ / docs. stripe. com/ payments/ checkout/ save- and- reuse - https:
/ / docs. stripe. com/ payments/ payment- methods/ payment- method- support - https:
/ / docs. stripe. com/ api/ setup_ intents
最终实施原则
先确认是否现在收费，再选择SetupIntent或PaymentIntent的未来使用配置；再区分凭证、客户关系、授权和展示许可；最后用webhook和本地状态机处理异步结果。任何“已保存”都必须同时回答四个问题：保存给谁、允许何时用、客户同意了什么、失败后如何召回客户。只有这四项都有证据，未来扣款流程才算完整。