SaaS 后台突然收到用户工单：提现按钮灰了，页面只写 account restricted。开发者第一反应往往是重发 onboarding link，但 Stripe Connect Express 的限制不一定在同一层：可能是 Account 的 requirements.past_due，也可能是 card_payments 或 transfers 这个 capability 没激活，还可能是 identity verification 已经进入人工查看。
先别让用户连续上传护照、公司文件和地址证明。Express 账户虽然由用户完成很多动作，但平台仍要把 API 里的字段翻译成可执行的提示，否则客服只能来回转发截图。
restricted 先看 Account 还是 Capability？
默认先取回 connected account 的 Account 对象，再查具体 capability。原因很简单：charges_enabled 和 payouts_enabled 直接告诉你收款和打款是否可用；requirements hash 告诉你缺什么；capability 只解释某一种能力为什么不能用。
| 后台信号 | Stripe 字段 | 更可能的含义 | 平台动作 |
|---|---|---|---|
| 不能收款 | charges_enabled: false | 收款相关能力未启用或资料未过 | 查 disabled_reason 和 requirements.errors |
| 不能提现 | payouts_enabled: false | 打款资料、银行或 KYC 卡住 | 先看 requirements.past_due |
| 某支付方式不可用 | capabilities.<id>.status | 单个 capability 未请求、待审核或受限 | 查 Capability 对象的 requirements |
| 用户刚提交资料 | pending_verification | Stripe 正在查看资料 | 不要立刻重复上传 |
| 用户说已经补完 | currently_due 仍有字段 | 字段没填全或验证失败 | 看 errors 里的 code 和 reason |
如果你只看 Express Dashboard 截图，很容易把 capability 问题误判成身份问题。平台后台至少要展示 connected account id、charges_enabled、payouts_enabled、disabled_reason、current_deadline 和最近一次 account.updated 时间。
requirements_due 到底是哪几个字段？
requirements_due 更像团队内部叫法，不是 Stripe Account 对象里单独的字段。实际排查时看这几组：requirements.currently_due、requirements.past_due、requirements.eventually_due、requirements.pending_verification 和 requirements.errors。
currently_due 是当前需要补的资料，通常要结合 current_deadline 看期限；past_due 是已经过期并可能禁用能力的资料，优先级更高；eventually_due 先放进材料清单，不要抢着让用户提交；pending_verification 说明资料正在被查看，客服话术要改成等待结果，而不是再次催传。
一个实用判断是：past_due 影响现金流，先处理；currently_due 影响期限，排期处理；eventually_due 影响未来，先预告用户。三类字段混在一封邮件里发给用户，只会让对方把所有文件都传一遍。
capability 受限时要不要马上请求更多能力？
不要为了「一次开全」把所有 capability 都请求上。Stripe 的 Connect capabilities 文档写得很清楚：请求的能力会决定需要收集哪些信息；请求越多，onboarding 需要验证的内容越多。有些能力还不能随意移除。
对一人 SaaS 或 marketplace，最常见的是 card_payments 和 transfers。如果你只是做 destination charge，先确认这两个能力的 status；如果新加本地支付方式，再单独看对应 payment capability。不要因为 p24_payments 或 sepa_debit_payments inactive，就误以为整个 Express 账户不能收款。
平台代码里也别只写一个布尔值 accountRestricted。更适合拆成三类状态：收款不可用、打款不可用、某个支付方式不可用。这样客服看到的不是红色大字「受限」，而是「需要账户负责人补地址证明」或「transfers 正在审核」。
identity verification 卡住时谁来补资料？
涉及 identity verification 时，最容易出错的是让运营同事代替账户负责人操作。Stripe 对 Connect 账户的验证会因国家、business type、business structure、服务协议和风险水平变化；有时只要证件，有时还要地址证明或自拍。
Express 账户能通过 Stripe-hosted onboarding、account link 或嵌入式组件补资料。平台可以生成入口，但身份证件、自拍、银行信息这类敏感动作通常应由账户负责人本人完成。你可以替用户解释字段含义，不能把「代传一份差不多的文件」当成解决方案。
看到 requirements.errors 时，先读 requirement、code、reason。比如文件过期、地址不匹配、税号格式不对、声明描述和业务 URL 不一致，处理方式完全不同。Stripe 文档还提醒，文件验证失败时不要重复提交同一份文件；重复上传可能自动失败。
SaaS 后台应该给用户显示什么？
用户不需要看到完整 JSON，但需要知道下一步由谁完成、补哪份材料、会影响收款还是提现。建议把字段转成四列：影响范围、缺失对象、用户动作、平台动作。
| 影响范围 | 缺失对象 | 用户动作 | 平台动作 |
|---|---|---|---|
| 收款 | card_payments requirements | 补账户负责人或公司资料 | 生成 onboarding link，监听 account.updated |
| 提现 | transfers requirements | 补银行、地址或身份资料 | 暂停提现按钮，保留账面记录 |
| 支付方式 | 单个 payment capability | 确认是否需要该支付方式 | 不需要就别请求，避免增加资料负担 |
| 人工查看 | pending_verification | 等待结果，不重复传文件 | 更新客服状态和下一次检查时间 |
后台文案要避免一句话甩锅给 Stripe。更好的写法是：你的提现能力正在等待身份资料验证，Stripe 返回的字段是 person.verification.document。请由账户负责人本人打开验证链接上传证件原件。
跨时区处理这类后台时，至少固定一个管理员操作窗口。需要频繁查看 Stripe Dashboard、生成 account link、比对 webhook 的团队，可以把 Stripe Dashboard 稳定访问 放进内部运维清单；它只能减少后台访问中断，不能替代 KYC 文件、真实业务证明或 Stripe 的审核判断。
什么时候该暂停自动化，改走人工工单？
看到 disabled_reason 是 requirements.past_due，通常还能按字段补资料推进；看到 under_review，先等 Stripe 查看；看到 rejected.*，就不是继续重发 onboarding link 能解决的事了。尤其是 rejected.fraud、rejected.terms_of_service、listed 这类原因，平台应该停止自动重试，改成内部风控和支持工单。
还有一类 interv_ 开头的 risk 或 compliance requirement，可能需要表单、challenge、notice、support 或 underwriting case。它不是普通字段缺失，客服不能用「再上传身份证」糊弄过去。把 connected account id、能力状态、disabled_reason、最后一次用户提交时间、业务 URL 和 webhook 事件整理好，再联系 Stripe 支持。
合规限制：平台能做什么，Stripe 仍会判断什么
这篇只讨论 Connect Express 在 SaaS 平台里的排查路径，不提供法律、税务或金融合规意见，也不判断某个国家、行业或个人是否一定能通过 Stripe 审核。Stripe 的验证要求会随国家、capability、business type、business structure、服务协议和风险水平变化。
平台能做的是三件事：准确读取 Account 和 Capability 状态；把字段翻译成用户能完成的动作；在 webhook 里及时更新业务状态。平台不能承诺审核通过，不能替账户负责人完成自拍或敏感身份确认，也不该为了降低工单量而隐藏 disabled_reason。