个人开发者无海外公司，怎样把 AI 产品收款从 Creem 迁到 Waffo Pancake？
一位没有海外公司、也没有港卡的个人开发者，在 Creem 风控封号后，改用 Waffo 面向开发者的 MoR 产品 Pancake，用大陆身份证完成 KYC、通过 AIGC 生产审核，并接入一次性积分包与月付年付订阅、绑定支付宝与国内银行卡提现。作者把品类自查、店铺自检、法律页整改、代码接入与提款验证整理成一条可照做的流程。
为什么推荐这篇
这类流程性复盘最有价值的部分不是费率数字，而是判断链条：先确认自己属于哪条通道，再判断品类风险，最后才是接入与提款。建议读者把它当作检查清单的索引，而不是照抄参数，因为支付平台的费率、支持国家和审核政策都会变，旧文里的数字随时可能失效。
对产品负责人来说，可以立刻做的一件事是把收银台、Terms、退款页和 AUP 放在同一张表里对齐，凡是口径不一致的地方先改掉；同时在代码侧确认权益发放只认服务端验签事件。若品类涉及高风险能力，与其反复申诉，不如先下线该能力、保留核心产品和搜索资产，再重新申请。
渠道层面应保留备用方案，不要把所有收入押在单一支付服务上；对低客单价产品，定价时必须把固定手续费、退款处理费和提款最低费一起算进去，避免规模上来反而亏损。
带着这些问题读原帖
- 你当前是否具备公司主体，应该走哪条通道？
- 你的品类和具体功能是否落在限制清单，能否先下线高风险能力？
- 收银台、Terms、退款与 AUP 的规则是否已经对齐？
- 权益发放是否只以验签后的服务端 Webhook 为准？
- 按当天官方费率与提款成本测算，你的客单价还能盈利吗？
- 如果该渠道再次风控，你的备用收款与迁移方案是什么？
以上问题根据原帖内容整理；本站推荐与验证建议由 AI 生成并检查。
领取体验，按开放范围继续阅读 ↗核心结论是：个人开发者做付费 AI 出海，先分清 Waffo 主通道与 Pancake 两条路线——前者面向已有香港、新加坡等地公司主体的商户，后者面向独立开发者与 AI/SaaS 小团队，可以无海外公司、以个人身份申请，本质是承担税务与销售方责任的 MoR。真正决定能否通过的，往往不是技术接入，而是产品品类是否踩到限制清单，以及 Terms、Privacy、AUP、客服邮箱、模型披露、退款规则能否逐项对齐收银台口径。
01 / 原作者披露了什么？
原帖只描述个人体验与流程，未给出可核验的统一周期或转化数据
- 原帖作者
- 独孤风
- 原帖日期
- 2026-09-01
原帖按生财账号权限阅读。以下适配判断、对比维度与验证建议由本站整理，不代表原作者建议。
02 / 先比较起点，再比较成果
更适合这样的你
- 没有海外公司或营业执照的个人开发者
- 做 AIGC 或 SaaS 订阅类数字产品并需要全球收款
- 愿意按官方清单整改法律页与内容审核流程
- 能接受以服务端 Webhook 而非前端跳转为准来发放权益
这些情况先缓一缓
- 依赖 Deepfake、人脸声音克隆、NSFW 等高风险能力作为核心产品
- 希望完全不改产品与法律页就快速通过审核
- 低客单价且高频小额提现、不愿核算固定手续费的卖家
- 把审核通过理解为可以随意更换产品网站的人
- 需要准备
- 官方禁止与限制品类页；店铺审核自检清单；Terms / Privacy / AUP 草稿；域名邮箱与客服邮箱；身份证法定姓名与收款账户；低客单价测试商品；服务端密钥与生产 Webhook 配置
- 先核对起点
- 有可公开访问的付费数字产品与真实定价；能提供大陆身份证完成 KYC 并持有与法定姓名一致的收款账户
03 / 我们怎么看这条路径？
机制上，MoR 由平台作为法律销售方处理全球税费、发票、退款与拒付，你负责产品、内容合规、交付与客服。因此平台审核的重心落在三件事：网站是否真实可理解、定价与权益是否透明、AIGC 风险是否被制度与代码双重约束。作者第一次被要求补充材料而非直接拒绝，正是因为合规团队点名了涉及高风险人物内容的功能，说明整改路径是可协商的。
个人开发者做全球收款，真正的门槛不是代码接入，而是把产品、法律页与内容审核做成一套经得起平台检查的一致口径；渠道选择要与自己的主体条件和品类风险匹配。
04 / 你的第一步可以怎么做？
以下是本站提出的小规模验证建议，不是原帖完整操作教程。
- 01
先对照官方禁止与限制品类做自查，必要时先下线具体高风险功能再提交
- 02
注册 Pancake，按真实情况填写个人身份、CN 地区与产品类目，绑定与法定姓名一致的收款账户
- 03
按自检清单补齐 Terms、Privacy、AUP、页脚客服邮箱、模型披露与退款一致性，并把支持邮箱放到全站页脚
- 04
先建一个低价一次性商品跑通测试支付与 Webhook，再补订阅与其余套餐
- 05
服务端用密钥创建 Checkout，配置生产 Webhook 并监听订单、订阅与退款事件，切到生产模式后小额验证提款
05 / 哪些条件容易被忽略？
- 费率、支持国家、提款方式与审核政策会变化，历史数字不能当作长期承诺
- 法定姓名与提款户名不一致、空格标点差异可能导致打款失败
- 把高风险功能保留下来可能只能走单一本地支付渠道，失去国际卡渠道
- 前端 Success 页面可能被伪造，仅凭跳转发货会造成漏单或盗刷
- 低客单价叠加固定手续费与提款最低费，利润可能被侵蚀
- 私钥若进入前端、Git 或截图，存在资金与账号安全风险
06 / 关于这个方向的常见问题
申请时官方当天公示的费率、提款最低额与支持国家是什么？
以申请当天的官方费率页、后台页面和工作人员书面回复为准，不沿用他人文章里的旧数字。
你的产品是否落在限制或禁止品类，AIGC 六类禁止内容是否逐项写入 AUP？
需要逐项列出禁止内容、举报邮箱、处置方式，并确认代码里确有审核动作。
收银台、Terms 与退款页对积分有效期、取消和退款的表述是否一致？
三处规则不一致是常见的自检失败原因，应以同一口径重写。
权益发放是否以验签后的服务端 Webhook 为唯一依据？
订单完成、订阅激活与支付成功等事件需在服务端校验后再发货。
提款户名与身份证法定姓名是否完全一致？
姓名顺序、空格与标点不一致都可能导致打款失败。
通过审核后能否更换成完全不同的网站？
官方口径是会审核该产品网站，通过后不支持随意替换。
个人开发者 MoR 接入核对表
本站原创练习。下表是填写示例，不是原作者的业务数据。下载后替换成你自己的信息。
| 核对项 | 证据 |
|---|---|
| 分类自查（示例） | 保存官方限制品类页截图与自查结论 |
| 法律页一致性（示例） | 收银台、Terms、退款页对积分与退款的表述截图 |
| 发货依据（示例） | 服务端验签日志中的订单或订阅事件记录 |
| 提款信息（示例） | 户名与身份证法定姓名的比对记录 |
- 你属于主通道还是 Pancake 通道，依据是什么？
- AIGC 六类禁止内容是否逐项写入 AUP 并有举报渠道？
- 哪些权益发放点仍依赖前端跳转，需要改为 Webhook？
下一步，带着这个案例的问题去继续阅读。
你已经读过公开答案、原创分析和验证清单。按实际开放范围继续核对这些问题，再决定是否适合长期加入。
- 你当前是否具备公司主体，应该走哪条通道？
- 你的品类和具体功能是否落在限制清单，能否先下线高风险能力？
- 收银台、Terms、退款与 AUP 的规则是否已经对齐？
- 权益发放是否只以验签后的服务端 Webhook 为准？
- 按当天官方费率与提款成本测算，你的客单价还能盈利吗？
- 如果该渠道再次风控，你的备用收款与迁移方案是什么？