把 Stripe payout 暂停拆成 8 个互不相同的问题。登录不了 Dashboard、账户资料没核验、银行账户失败、税表字段缺失、业务被要求做 supportability review、争议太多、负余额和排款节奏，处理入口完全不同。
2026-05-23 比对 Stripe 官方资料后，最值得先看的不是邮件标题，而是 Dashboard 或 API 里的 payouts_enabled、charges_enabled、requirements.currently_due、requirements.past_due、requirements.pending_verification 和 requirements.disabled_reason。这些字段能告诉你是「还缺资料」「逾期未补」「Stripe 正在审」还是「银行侧失败」。
先分清是哪一层的问题
分清三层：你能不能登录、账户能不能收款、余额能不能打到银行。Stripe 后台登录异常不是 payout 暂停；charges disabled 也不是 payout schedule 延迟。
| 现象 | 更像哪一层 | 第一动作 |
|---|---|---|
| Owner 进不了 Dashboard，团队其他人能进 | 登录访问 | 恢复 2FA、团队权限和邮箱，不先改账户资料 |
| Dashboard 显示 verification needed | 账户验证 | 打开 Requirements，逐项记录 currently_due / past_due |
payouts_enabled: false，charges_enabled: true | 只影响打款 | 查 verification、银行、税表、负余额和 payout settings |
charges_enabled: false 也出现 | 收款能力也受影响 | 优先看 disabled_reason 和 Stripe 邮件原文 |
| payout 显示 paid，银行没到账 | 银行处理或失败 | 查 Payouts 页面、银行流水和失败通知 |
| 第一笔 payout 很久没来 | 初始排款或风险/国家差异 | 对照 payout availability，不承诺固定恢复日 |
如果你用 API 或 Connect，把 Account object 拉出来；如果只用 Dashboard，保存 Requirements、Payouts、Disputes、Bank accounts、Business details 五处截图。不要先写长邮件解释商业模式，字段没对齐时解释通常没用。
把登录访问和账户验证分开查
要分开。登录访问解决的是「谁能看到和操作 Stripe」；账户验证解决的是「Stripe 是否认可这个账户继续收款或出款」。把两者混在一起，会让团队反复改密码、换设备，却没有补上真正 past_due 的资料。
登录访问先查 4 件事：Owner 是否还能登录、管理员是否有足够角色、2FA 是否可用、Stripe 安全邮件是否能收到。团队里只剩一个 Owner，是 payout 暂停时最危险的配置，因为争议、退款和资料上传都可能卡在同一个人的设备上。
账户验证看 Requirements。Stripe Connect 文档把 currently_due 用来表示当前必须补的字段，past_due 表示错过期限的字段，pending_verification 表示已经提交但还在审或异步核验中。disabled_reason 则解释能力为什么被挡住。
补齐代表人与受益所有人资料
Stripe 要看的不是「创始人是不是本人」，而是账户、公司、代表人、owner、director、银行账户和网站是否能互相印证。代表人通常要有权代表公司接受 Stripe 条款；受益所有人常见口径是 25% 以上 ownership，部分国家还会看 executive、director 或 proof of authority。
| 资料桶 | Stripe 可能在看什么 | SaaS 团队准备什么 |
|---|---|---|
| Business representative | 谁有权代表公司开通账户 | 护照/ID、生日、地址、职位、授权证明 |
| Beneficial owner / UBO | 谁拥有或控制公司 | 25% 以上 owner、股权表、Operating Agreement 或注册文件 |
| Company information | 实体是否存在、名称地址是否一致 | Certificate、EIN Letter、公司地址证明、网站 footer 法定名 |
| Tax ID / EIN / VAT | 税号是否能匹配实体 | IRS Letter 147C、SS-4 confirmation、VAT ID 或本地税号文件 |
| Bank ownership | payout 银行账户是否属于账户主体 | bank statement、voided check、routing/account 后四位截图 |
| Website supportability | 卖什么、怎么交付、怎么退款 | Home、Pricing、Terms、Privacy、Refund、Contact、产品截图 |
这里不要新开一个 Stripe 账户，也不要把业务描述改成和真实产品不一致的行业。Stripe restricted businesses 页面明确把误导陈述和规避控制列为不可接受行为；审核时前后说法冲突，会比单项材料缺失更难解释。
银行账户与 payout schedule 排查
银行问题的信号很具体：payout 页面有 failure reason、邮件有失败通知、银行账户币种或账户类型不匹配，或者 payout 一开始显示 paid，几天后又变成 failed。Stripe payouts 文档写明，银行确认失败并退回资金可能最多再花 5 个工作日。
按这个顺序查：
- Payouts 页面里这一笔是 pending、in transit、paid 还是 failed。
- Payout settings 里的银行国家、币种、账户名和账户类型是否匹配。
- 银行账户是否支持 credit 和 debit transactions，避免 Stripe 无法做 payout 或 reversal。
- 如果银行资料错了，修银行信息，再点 Stripe 提供的 Resume Payouts。
- 重新排款后，用 payout id 去银行流水找 posted date，不用余额猜。
排款节奏不是风控。Stripe 文档说明，payout schedule 决定何时打款，settlement timing 决定资金何时可用；第一笔 payout 通常安排在首笔成功付款后的 7-14 天，但会受国家和风险级别影响。不要把 T+3 settlement、周末、银行假日和 payout disabled 混在一起。
税表、限制行业和争议对 payout 的影响
税表先看你是不是 Connect 平台或启用了 1099 相关能力。Stripe 的 1099 税务验证文档写得很具体：如果 1099 capability 开启，账户达到 600 USD charges 时，必填税务信息未收集并核验，payouts 会被禁用；已经超过 600 USD 的账户开启能力，也可能立即禁用 payouts。这不是每个普通 SaaS 直连账户都会遇到，但做 marketplace、creator payout、affiliate payout 的产品要提前收集 TIN、姓名和地址。
限制行业 review 不等于一定被拒。Stripe 把业务分成 prohibited 和 restricted；restricted 往往要额外审核或预先批准。AI SaaS 常见卡点不是「用了 AI」本身，而是网站说不清客户买什么、是否涉及高风险金融服务、成人内容、赌博、受制裁地区、代收代付或承诺收益。
争议和 chargeback 则是现金流问题。Stripe disputes 文档写明，正式争议通常只有 7-21 天回应窗口；提交证据通常只有一次机会，文件大小限制 4.5MB，Mastercard 证据还有 19 页限制。payout 暂停时，更要按时处理争议，因为输掉争议会让余额和后续 payout 更难看清。
准备 Support 证据包
给 Support 的材料要短、准、能对字段。不要发 20 张无序截图，也不要把客户完整个人信息、完整卡号或内部风控规则贴进去。
| 证据 | 推荐写法 | 对应问题 |
|---|---|---|
| Account 状态 | payouts_enabled=false / charges_enabled=true / disabled_reason=... | 证明阻塞层级 |
| Requirements 截图 | currently_due、past_due、pending_verification 各 1 张 | 证明你按字段补资料 |
| 邮件原文 | Stripe 发件人、主题、时间、case id | 对齐官方通知 |
| 公司和代表人 | 法定名、EIN/税号尾号、代表人职位 | 账户验证 |
| 银行资料 | bank statement、账户名、币种、后四位 | 银行归属与失败 payout |
| 业务页面 | Pricing、Terms、Privacy、Refund、Contact 链接 | supportability review |
| 交易样本 | 最近 3-5 笔 PaymentIntent / Invoice id | 运营真实性 |
| 争议/退款 | dispute reason、due date、退款记录 | chargeback 风险 |
| 时间线 | 何时发现、何时补件、何时失败 | 减少来回邮件 |
邮件正文控制在 6 行：账户、现象、开始时间、已完成动作、业务影响、附件清单。不要要求 Support 给固定恢复时间；如果官方页面没有给 timeline，就只问「还缺哪个字段」和「当前 disabled_reason 是否仍成立」。
payout 暂停期间的业务连续性
停付期间最怕把所有人力都放在「等 Stripe 回复」上。客户退款、争议截止日、发票、订阅取消、客服承诺和银行对账不会暂停。
运营清单如下：
- 每天固定一次查看 Dashboard、邮箱和 webhooks，不全天反复刷新。
- 给财务表加一列
payout_status，把 pending、paid、failed、paused 分开。 - 退款按政策处理，别因为 payout 暂停就拖到客户发起争议。
- Disputes 页面单独盯
evidence_due_by，争议证据先于普通对账。 - 高金额年付新订单先人工复核，避免在审核期增加异常波动。
- 客服话术只说「收款后台正在做账户验证」，不要承诺 Stripe 未确认的恢复日。
- 现金流表按保守口径计算：把未到账 payout 视为不可用资金。
payout 恢复前的运营要点
判断是「你还没补完」还是「Stripe 还在审」。currently_due 还有项目，就继续补字段；pending_verification 还在，就整理证据等审核结果；past_due 已经影响能力，就把 Support case、补件记录和业务影响放在同一个时间线里。
如果 payout 失败来自银行，按 Stripe 的失败原因修银行资料，点 Resume Payouts 后等下一次 schedule；如果来自 restricted business review，不要再改行业词逃避审核，而是用真实网站、产品截图、客户合同、退款政策和交付记录证明业务可支持性。
如果团队在旅行、联合办公和远程办公室之间切换，处理 Stripe、银行、邮箱和公司文档时，最好固定设备、浏览器 profile、密码管理器和网络环境。可以用Stripe Dashboard 稳定访问承载这些财务后台操作；它只能减少登录和会话变量，不能替代身份核验，也不能让不符合政策的业务通过审核。
如果 charges 也被 disabled，准备备用收款只做业务连续性：银行转账、invoice、MoR 或其他合规渠道都要如实告知客户和会计。备用渠道不是让你规避 Stripe 审核，后续对账也要保留 invoice、合同、退款和税务记录。