AI 做的产品怎么收款？个人开发者支付接入实操（2026）

用 AI 把产品做出来、部署上线、加上报错监控之后，绝大多数人会撞上同一道墙：怎么收钱。这道墙的难点根本不在代码——支付 SDK 的调用代码 AI 十分钟就能写完——而在于资质、渠道和平台规则：你有没有营业执照、卖的是实物还是虚拟内容、产品跑在网页里还是 iOS App 里、用户在国内还是海外，四个变量组合出来的路径完全不同，选错了要么根本申请不下来，要么上线后被平台封停。这篇文章把个人开发者支付接入的路径讲清楚，并给出让 AI 写支付代码时绝不能松的几条红线。

先回答四个问题，路径就定了

别一上来就搜「怎么接微信支付」。先把这四个问题答一遍，你会发现可选项一下子从十几个收敛到一两个：

1. 1你有营业执照吗？ 有个体工商户执照，就能申请微信支付/支付宝的标准商户号，走官方接口，这是最规范的路；没有执照，可选渠道会少很多，而且大多对「线上虚拟商品」不友好。
2. 2你卖的是实物还是虚拟内容？ 课程、会员、软件授权、AI 额度这类虚拟商品，是各平台风控和抽成的重点对象，规则明显严于卖实物。
3. 3你的产品跑在什么壳子里？ 网页/H5 最自由；iOS App 卖数字内容必须走苹果内购；微信小程序卖虚拟商品从 2026 年起必须走官方虚拟支付接口。这一条最容易被忽略，也最容易致命。
4. 4用户在国内还是海外？ 国内用户就是微信支付/支付宝二选一或都要；海外用户几乎一定要走 MoR（Merchant of Record，记录商户）平台，而不是自己扛税务。

国内收款：四条路怎么选

国内收款绕不开微信支付和支付宝这两家。它们的差别不在技术，而在「主体资质」这道门槛上。微信支付官方支持的申请主体包括小微商户（无营业执照的个人商家）、个人卖家（无执照但需满足持续经营时长与营收门槛）、个体工商户、企业等类型；支付宝这边个人也能签约部分产品。整理成一张表：

我的建议很直接：如果你打算把这个产品当成一件正经事做下去，直接去办一张个体工商户营业执照。现在个体户线上申请流程已经很轻，拿到执照后微信支付和支付宝的标准商户号都能正常申请，官方接口文档完整、AI 也最熟悉，费率透明（线上普通商户普遍在 0.6% 左右，具体以签约为准），后续开票、对账、涨流水都不会卡。反过来，为了「省一张执照」去挤各种个人通道，往往在虚拟商品这一类上直接被挡住，白折腾几周。

最容易致命的坑：你的产品跑在谁的壳子里

很多人接支付卡住，不是因为申请不下来商户号，而是因为忽略了「渠道方也要抽成、也有规则」。同一份代码，放在网页里能收 100 元，放进 iOS App 就只能到手 70 元甚至更少。三种情形要分开看：

这里有个非常实际的结论：如果你的产品主要卖虚拟内容（课程、会员、AI 额度），优先把交易发生在自己的网页上，App 和小程序只做体验入口。这不是在钻空子——各平台规则明确禁止的是「在它的容器内引导用户去外部支付」，而用户自己在浏览器里访问你的网站完成购买，是另一回事。具体边界随平台政策变化，涉及金额较大时值得认真读一遍最新规则再定架构。

卖给海外用户：让 MoR 平台替你扛税务

面向海外收款，真正的麻烦不是收钱，而是各国的销售税/增值税（美国各州 sales tax、欧盟 VAT 等）合规。MoR 平台的价值就在这里：它以「记录商户」的身份完成交易，代收代缴各地税费、开发票、处理退款和拒付，你只管拿结算款。代价是费率比纯支付网关高一截。

让 AI 写支付代码：四条不能让它自由发挥的红线

支付是整个产品里唯一「写错就直接丢钱」的模块。AI 写支付代码的问题不是语法错误，而是它倾向于产出「happy path 能跑通」的最短实现——把验签、幂等、金额校验这些不影响演示效果的部分省掉。这四条必须由你逐条检查：

1. 1金额永远由服务端算，绝不接受前端传入。 下单接口只接收商品 ID 和数量，价格从数据库里查。让 AI 写下单接口时它经常直接用请求体里的 amount——这等于把改价权限交给了用户，抓包把 99 元改成 0.01 元就成交了。
2. 2回调必须验签，验签失败要返回错误而不是静默忽略。 平台通知一律先用原始报文验签（注意不要先反序列化再拼回去签，那样签名对不上）。验签不通过应答 4xx/5xx，让平台按机制重发；直接 return 200 会让真实通知被吞掉。
3. 3回调必须幂等。 平台明确会重复发送同一条通知，重复处理就意味着重复发货、重复加余额。做法是用订单状态作为条件更新（where status = 'pending'），更新行数为 0 就说明已处理过，直接应答成功。
4. 4先应答，再做耗时的业务。 通知应答有超时限制，把发邮件、生成文件、调第三方这些慢活放在应答之后异步做，否则平台会因超时不断重试。另外一定要有对账机制——每天把自己库里的订单和平台账单对一遍，这是发现「钱收到了但权益没开通」的唯一可靠手段。

// 支付回调的正确骨架（以订单号 outTradeNo 为幂等键）
export async function POST(req: Request) {
  // 1) 先拿原始报文——验签必须基于原始字节，不能先 parse 再拼回去
  const raw = await req.text();

  // 2) 验签失败：返回非 2xx，让平台按重试机制重发，而不是静默吞掉
  if (!verifyPlatformSignature(req.headers, raw)) {
    return new Response('invalid signature', { status: 401 });
  }

  const event = parseNotification(raw); // 按平台文档解密/解析
  if (event.tradeState !== 'SUCCESS') {
    return Response.json({ code: 'SUCCESS' }); // 非成功态，确认收到即可
  }

  // 3) 幂等：把订单状态当乐观锁，只有 pending -> paid 这一次会成功
  const result = await prisma.order.updateMany({
    where: { outTradeNo: event.outTradeNo, status: 'pending' },
    data: {
      status: 'paid',
      paidAt: new Date(),
      transactionId: event.transactionId,
    },
  });

  // 更新到 0 行 = 这条通知之前已经处理过，直接应答成功，绝不重复发货
  if (result.count === 0) {
    return Response.json({ code: 'SUCCESS' });
  }

  // 4) 金额只和自己库里的订单核对，请求里的价格一律不信
  const order = await prisma.order.findUnique({
    where: { outTradeNo: event.outTradeNo },
  });
  if (!order || order.amount !== event.amount) {
    // 金额不符：记录告警并人工介入，不要自动发货
    await alertMismatch(event);
    return Response.json({ code: 'SUCCESS' });
  }

  // 5) 先应答，耗时的发货/通知逻辑丢给异步任务
  void grantEntitlementAsync(order.id);
  return Response.json({ code: 'SUCCESS' });
}

上线前自查清单

• 商户号资质与实际经营内容一致（拿零售类目去卖虚拟课程，是被冻结结算的常见原因）。
• 密钥、证书、API v3 密钥全部放在服务端环境变量里，没有进 Git，也没有出现在前端代码里。
• 回调地址是 HTTPS，且做了验签；本地开发用的临时隧道地址没有留在生产配置里。
• 订单表有唯一的商户订单号，并对幂等键加了唯一索引。
• 退款、关单、超时未付的流程都跑通过一次，且退款会同步收回权益。
• 有一份能对账的记录：每笔订单的平台交易号、金额、时间都落库了。
• 页面上有清晰的服务说明、退款政策与联系方式——这既是平台审核要看的，也是减少纠纷的关键。
• 价格展示、发票/收据、以及涉及订阅时的自动续费提示，都符合平台与消费者权益的要求。

收款这一步之所以让很多人卡住，是因为它第一次把「做出来」和「交付给真实用户」之间的差距摊开了：资质、平台规则、资金安全、对账，没有一项能靠让 AI 多写几行代码解决，但每一项都有明确的套路可循。把它跑通，你的产品才算真正闭环。想系统地走完从想法、开发、部署、监控到变现的整条链路，欢迎来 IMAI 看看我们的体系化实战课程。