Stripe 把你封了？灾备预案 + 还能登录时怎么迁订阅（2026）

先接受残酷的版本：Stripe 彻底封号通常意味着你完全进不去了——后台登不了、订阅导不出、客户邮箱拿不到。所以这篇其实是两篇合一：趁一切还正常时该搭的冗余，和门已经摔上之后的抢救打法。外加官方迁移工具箱——只在你还能登录的幸运情形下可用。

现实：封号 = 锁死在门外

这不是「暂停、补料、恢复」。终止（termination）是锁死账户：你脑子里那套「先导数据再迁移」的计划，恰恰是做不了的那件事。正在跑的订阅全部开始扣款失败；联系不上的客户悄悄流失；现金流当天断掉；余额通常还要被扣 90–180 天。业务越大越致命——所以真正的功夫在事前。

被封之前：冗余怎么搭

• 至少两条独立收款链：2 个 Stripe 账户挂不同法人主体 + 2 个美国对公账户。主账号跑大头，备用账号保温。
• 独立是全部要点：不同公司、不同信息。一套资料开多个号 = 一次审查连坐一串。（前提是业务本身合规——冗余是业务连续性保险，不是钻空子工具包；违规业务的所有账号会一起没。）
• 备用号要养着：平时有真实的、偶发的流水。零历史的空壳，接不住 24 小时内砸过来的业务。
• 用户邮箱名单必须攥在 Stripe 之外。封号之后，Stripe 里那份名单对你等于不存在。这一个习惯，决定了 Plan B 是否存在。

已经被封、没做冗余：Plan B

1. 认清失去的：旧账户里的数据你已经动不了。唯一的路绕过 Stripe——直接找你的用户。
2. 先把落点立起来：新 Stripe（不同主体）+ 对公账户。要好几天——立刻开始；没有落点的重订阅号召只是噪音。
3. 给自己的名单发邮件：简短说明情况、附新订阅链接、请用户重订。给点小激励，效果明显。
4. 接受损耗：重订有摩擦，有人嫌麻烦，有人趁机退订。能挽回约 70% 的订阅者已经算*好*结局——这个数字就是没做冗余的真实价格。

还能登录？官方迁移工具箱

如果账户还进得去（你在换主体、降风险，或者赶在限制升级前跑路，而不是已被彻底封死），Stripe 官方的 Billing 迁移工具箱（Dashboard → Subscriptions → Migrations）用一份 CSV 就能把订阅在账户间搬家——免费、官方、Stripe→Stripe 不需要 PAN import。

1. 准备：新号先搭好 Billing；在新号重建 Products 和 Prices；先在 sandbox 跑一小批。
2. 填 CSV：必填——customer、start_date（≥24 小时后、epoch 格式）、price、quantity；Stripe→Stripe 的 metadata 填 internal:Stripe。对齐计费周期用 billing_cycle_anchor / collection_method / trial_end。
3. 上传（≤120MB，自动校验）→ 核对汇总 → Start migration → 追踪。
4. 时间机制：迁过去的订阅先处于 *scheduled*，24 小时后才 go live；调度后有 10 小时窗口可以在工具箱里取消迁移——过了就只能走 API 或逐个取消。
5. 上线后：盯首次扣费（金额和日期）、盯支付失败、催换过期卡。量大就先小批试点，再分批并行。

迁移的三个坑

• 重复扣费——经典坑。先在新号建好订阅，再在旧订阅*下次扣款前*取消它；续费日临近的，把新订阅排到旧号最后一笔之后开始，让每个计费周期只有一边在扣。
• 填错账号的 ID——CSV 里所有 ID（customer / price / coupon / tax）必须是目标账号（新号）的。填源账号的直接报错；先在新号建好 Products / Prices、用新 ID。
• 没有默认支付方式——凡 charge_automatically 的订阅，客户在目标账号必须有默认支付方式，否则被拦。（send_invoice 的只需要邮箱。）缺的提前补，别等报错。

结论

• 真正的封号是锁死——抢救窗口在事前，不在事后。
• 冗余 = 两个主体、两个 Stripe、两个对公账户、备用号保温——外加攥在 Stripe 之外的邮箱名单。
• 已经被封：先立新落点，再发重订阅邮件；挽回约 70% 就是赢。
• 还能登录：官方工具箱能迁订阅——防重复扣费、用目标账号 ID、补默认支付方式。
• 这一切救不了不合规的业务。冗余买的是连续性，不是豁免权。