1. 把页面跳转与账户就绪分开
关联账户完成流程或点击 Save for later，Stripe 都会把用户送回 return_url。这不表示所有信息已收集，也不表示账户没有待满足的要求。[2] 应把回跳理解成导航事件：用户回到了应用，但服务器仍需确认账户究竟处于什么状态。
建议先显示正在检查，再根据登录用户绑定的账户读取最新信息，随后展示下一步。不要因为浏览器访问了某条成功路径就显示审核通过。用户只填写一部分、关掉浏览器或在要求变化之后回来，都可能让单纯依赖页面路径的状态判断产生误导。
2. 在已认证会话内生成链接
Account Link 是临时、一次性的入口，因为它能访问账户持有人的个人信息。Stripe 要求跳转前认证用户，并明确不应通过邮件、短信或其他应用外渠道发送该链接。[2] 客服邮件应引导用户回到你自己需要登录的入驻入口，而不是粘贴之前保存的 Account Link。
创建链接时需要关联账户编号、refresh_url 和 return_url。collection_options.fields 使用 currently_due 表示逐步收集，使用 eventually_due 表示提前收集。[2] 建议在服务端保存这次选择，方便恢复路径重建同一个流程；临时链接则不要进入常规客服对话记录，以减少误分享风险。
3. refresh 必须生成新链接
链接过期、已经访问或无效时，Stripe 会使用 refresh_url。文档特别指出，聊天工具的链接预览可能自动访问链接，使它在用户真正打开之前就失效。[2] 因而刚生成就打不开，并不能单凭这一现象判断为业务被拒绝或身份审核失败。
官方要求 refresh 路由调用服务器，使用相同参数创建新的 Account Link，再跳转到新地址。[2] 作为实现防护，关联账户应从已认证会话解析，而不是信任用户可以自由修改的账户参数。生成失败时应显示可恢复的错误并允许重试，避免在旧地址和返回页面之间无限循环。
4. 返回后检查最新 requirements
return URL 不会传递状态。Stripe 建议读取账户并检查 requirements，或监听 account.updated 并在应用中缓存账户状态；如果入驻未完成，应提供以后继续的入口。[2] 普通浏览器请求命中返回路由，不是经过签名的验证结果声明，不能替代服务器核验。
应用内部宜区分已退出流程、仍需补充资料和账户实际运营状态。要求会随国家、业务类型和所申请能力而不同，也可能随时间变化。[2] 旧快照显示无需操作，不应阻止后续账户更新生成新的任务。本文只讨论入驻资料流程；具体能力和出款是否可用，还需进入你自己的账户就绪检查。
5. 选对继续填写的流程
account_onboarding 可用于新账户，也可为因新能力等原因产生额外要求的既有账户收集缺失资料。account_update 则有不同限制：只适用于平台负责收集要求的账户，不适用于能够访问 Stripe 托管 Dashboard 的账户。[2] 不要把所有损坏的入驻链接都替换成 account_update 当作通用修复。
托管入驻支持网页浏览器，不支持移动或桌面应用内的嵌入式 web view。正式环境 refresh 和 return 地址必须使用 HTTPS，测试环境才可以使用 HTTP。[2] 上线前应检查实际部署参数；本地 HTTP 回调成功并不能证明正式回调配置合格。
6. 分别测试退出、失效与恢复
建议覆盖完整填写、Save for later、链接已访问、链接过期、未登录访问 refresh，以及创建新链接失败。每种情形记录账户编号、经历的路由、最新 requirements 快照和展示的下一步。这是建议的测试计划，不是本文执行过的真实 Connect 账户实验。
验收标准不应是所有路径都能到达成功页面。旧链接应为正确的已认证账户生成新链接；未完成流程应给出继续提示；已经完成流程也应依据最新账户数据判断。Stripe 的 account.updated 会通知要求和账户资料变化。[2] 应将这些变化与用户看到的状态对齐，但不要在普通应用日志中存储身份证明文件。
来源与日期
以下为 Stripe 官方英文文档。未注明发布或更新日期；抓取核验日期为 2026-09-21，不把抓取日当成来源发布日期。本文为编辑研究，不代表 PayIn 产品能力、账户资格验证或法律意见。
- [2] Stripe-hosted onboarding · 核验 2026-09-21；原文日期未注明。