产品还在 waitlist，创始人先接 Paddle，结果审核要求补网站和业务说明。先别把它当成普通网络波动；Paddle account verification 看的是网站、业务、公司和 Merchant of Record 风险是否能互相证明。越多人同时改落地页和主体资料，越容易前后矛盾。
Paddle account verification 从哪一页判断
域名内容和主体资料互相支撑，把 domain review、business identification 和受限行业三个问题分开，再决定补网站还是补公司文件。
| 看到的信号 | 更可能的原因 | 第一动作 |
|---|---|---|
| domain review | 网站信息不足 | 补产品、价格、条款 |
| business identification | 主体或代表人待验证 | 准备公司和身份文件 |
| 受限业务 | 业务类型不被支持 | 看 Paddle 支持范围 |
上线前网站要有哪几页？
至少要有首页、产品功能、价格或申请入口、隐私政策、服务条款、退款或取消说明、联系方式。页面文字不要和 Stripe、Lemon Squeezy 后台写成不同业务。团队内部可以先用一份 vendor profile 统一描述：公司名、产品名、客户、收费方式、履约方式和支持邮箱。
哪些动作会把问题弄乱？
空壳落地页很难证明真实业务。同一时间只改一个变量：网站文案、价格页、公司文件、support 邮箱和业务说明要分开。团队里最好指定一个负责人回复 Paddle，其他人只补页面链接和截图。
| 不要同时改 | 为什么 | 替代做法 |
|---|---|---|
| 网站文案和业务说明 | 两边说法不一致会被退回 | 先统一 vendor profile |
| 公司文件和联系人 | 主体链路不清 | 标清 representative |
| 产品 waitlist 和收费入口 | 空壳页难证明业务 | 补真实功能与条款 |
留给团队的记录长什么样？
记录表不用复杂，6 列就够：时间、页面 URL、后台提示、补充文件、业务说明版本、下一步负责人。涉及 Merchant of Record 审核时加产品交付方式和退款说明。
网络和后台环境放在哪一步？
如果 Paddle、Stripe 和公司邮箱后台都在审核期，先固定负责人和登录环境，再排网站、business identification 与 Merchant of Record 风险。Stripe Dashboard 稳定访问适合承载出海团队的核心后台操作，但它不能替代真实网站内容和业务说明。
Paddle 审核不覆盖什么
Paddle 是否接收某类业务由其审核决定；这篇不覆盖成人、金融、加密、药品等敏感行业的专项要求。