AI应用加支付前必看：五个常见坑与自查清单

用 Claude Code、Cursor 或 Codex 做出一个能跑的应用不难，难的是收款之后它还能正常工作。独立开发者 Deepak 在海得拉巴踩遍了 AI 建站加支付的所有坑，把经验写成了一份不需要读代码也能照做的指南。

核心结论很朴素：结账按钮是最简单的部分，真正的 bug 藏在用户付款之后——它们不会出现在演示里，只会出现在第一封真实客户邮件里：“我付了钱，为什么进不去？”

钱到底是怎么流动的

先把整个流程用大白话拆开：用户在应用里点“升级”，被送到 Polar 或 Stripe 托管的结账页填写卡号（你的应用从不接触卡号，这是好事）；支付完成后用户被送回“感谢页”；另一边，支付公司会在后台给你的应用发一条短消息——“这个人刚为 Pro 付了款”。开发者管这叫 webhook，Deepak 把它简称为支付消息。

应用收到消息、验证真伪、在数据库里记下“此人是 Pro”；之后每次打开付费页面，应用先查这条记录再决定放行。

这里的关键认知是：感谢页本身不能证明任何事，任何人都能访问感谢页；真正解锁权限的应该是那条支付消息。后续的取消、退款、卡片失效，也通过类似的消息通知应用。绝大多数 bug 都出在收消息、验消息、写记录这三个环节。

Webhook（网络钩子）是一种“反向 API”机制：不是你的应用主动去问支付公司“有人付款了吗”，而是支付公司在事件发生时，主动向你的应用预先注册的一个 URL 发送 HTTP POST 请求，请求体里包含事件详情（谁、付了多少、买了哪个套餐）。这种推送模式让状态同步接近实时，但也带来两个工程要求：第一，该 URL 必须公开可访问；第二，因为公开，任何人都能向它发请求，所以必须验证请求确实来自支付公司——通常通过签名密钥（如 Stripe 的 Stripe-Signature 头）对请求体和时间戳做 HMAC 校验。此外，支付公司不保证消息按发生顺序到达，也不保证只发一次，因此应用需要具备幂等处理与“忽略过期事件”的能力。

五个高频故障与对应自查法

故障一：付了钱仍被锁在门外

结账成功、钱到账，但账户状态没更新。常见原因是支付消息根本没送达，或送到了被忽略，也可能是应用无法把付款和具体用户对上号（比如结账时用了另一个邮箱）。

自查方式：在测试模式下注册一个全新用户，用测试卡支付，看付费功能是否自动解锁；然后退出重登，确认仍然解锁。只要你需要手动修某个人的账户，就说明它是坏的。 另外打开支付公司的后台，那里会显示发给应用的消息是送达还是失败。

故障二：取消订阅后仍保留付费权限

用户取消了，权限却没收回。更隐蔽的版本是消息乱序：一条旧的“此人有效”消息在“已取消”消息之后才到达，应用又把权限还了回去。

自查方式：测试模式下订阅再取消，权限应持续到已付费周期结束才停止——不能立刻停，也不能永不停止。退款流程同样测一遍。然后直接问你的 AI 助手：“如果一条较旧的支付消息在较新的消息之后到达，应用会忽略它吗？”

故障三：伪造的支付消息能白嫖高级功能

应用有一个公开地址来接收支付消息。如果不校验消息确实来自 Polar 或 Stripe，任何找到这个地址的人都能发一条假的“此人已付款”，免费拿到高级权限。支付公司会给每条消息盖上密钥戳，但 AI 助手有时会跳过校验，或者在报错后干脆把校验关掉。

自查方式：让助手向你应用发送一条不带密钥戳的伪造“支付成功”消息，应用必须拒绝。如果能解锁任何东西，上线前必须停下来修。顺带确认密钥存在应用配置里，而不是硬编码在代码中。

签名验证是防止伪造支付消息的核心手段。以 Stripe 为例，它用你的 webhook 密钥对“时间戳 + 请求体”计算 HMAC-SHA256，放在请求头里；你的应用用同一密钥重新计算并比对。Polar 也采用类似的签名机制。关键点在于：验证必须基于原始请求体（raw body），而不能是框架解析后的 JSON 对象，因为重新序列化会改变字节，导致签名永远对不上。许多 AI 生成的代码在这里出错，或者为了“让测试通过”而注释掉验证——这正是故障三的根源。正确做法是把验证封装成不可绕过的中间件，并在测试中显式发送无签名请求确认被拒。

故障四：AI 凭空发明不存在的支付功能

支付公司接口更新频繁，而 AI 的训练数据停留在旧版本，于是它自信地写出看起来对、实际用了已改名、已删除或从未存在的参数。最糟的情况是静默失败，直到真实付款没解锁任何东西才被发现。

自查方式：要求助手严格遵循你所使用版本的官方文档，并说明每个步骤出自哪一页文档；然后在测试模式跑完整流程，从点击“升级”到功能解锁。“能编译通过”不等于“能正常工作”。

故障五：免费用户点开账单页就报错

你加了个“管理账单”按钮方便客户换卡或取消。免费用户点进去，因为从未付过款，支付公司没有他的记录，页面直接报错。

自查方式：用一个从未付费的免费账号登录，把所有与账单相关的入口都点一遍。要么对从未付费的人隐藏该按钮，要么展示一句友好的“您当前是免费版”。

如果你有多个套餐，还有一条附加检查：买最便宜的那档，确认它永远不会解锁更贵套餐的功能。

上线前自查清单

以下清单在测试模式下逐条跑一遍，花不了多少时间，能挡掉大部分“我付了钱为什么进不去”的邮件：

• 全新用户用测试卡支付，付费功能自动解锁
• 退出重登后功能仍解锁
• 取消订阅，权限在已付费周期结束时终止
• 退款后权限收回
• 不带密钥戳的伪造支付消息被拒绝
• 免费用户打开账单页不报错
• 最便宜套餐不会解锁更贵套餐
• 支付后台显示消息送达而非失败
• 密钥存放在应用配置而非代码中
• 服务条款、隐私政策、退款政策页面存在且可从站内链接到（支付公司常会要求）
• 上线后自己用真卡真实购买一次，确认解锁，然后退款

最后一条尤其重要：测试模式和正式模式使用不同的密钥与配置，很容易改了一边忘了另一边。

Polar 还是 Stripe：差别在谁管税

两者都可靠，最实际的区别在于谁负责销售税。

Polar 是所谓的“记录商户”（merchant of record）：纸面上它是卖家，负责在你客户所在国家收缴销售税和增值税，再把钱结算给你。对面向全球销售数字产品的独立开发者来说，这省掉了一大堆文书工作。代价是单笔费率高于 Stripe 的基础费率，具体要看它当前的定价。

Stripe 只处理支付，卖家是你自己，税务是你的责任。Stripe 有税务附加组件可以计算并代收正确金额，但注册和申报仍要你自己来。换来的好处是控制力更强，适合已有 Stripe 账户或有特定需求的场景。

Deepak 的经验法则是：独立开发者、卖数字产品或订阅、客户遍布多国、不想操心税务，从 Polar 起步；已有 Stripe 账户或公司本身能处理税务，就用 Stripe。无论选哪个，动手前先确认它能把钱结算到你所在的国家。税务问题拿不准的话，找会计师聊半小时是值得的。

需要强调的是：上面那些 bug 与选哪家无关，它们取决于你的应用如何响应支付事件，而非谁来处理支付。

记录商户（Merchant of Record, MoR） 是一种法律角色：在交易中，MoR 是名义上的卖家，对客户承担退款、税务、合规等责任。Polar、Paddle、Lemon Squeezy 都属于 MoR 模式。对独立开发者而言，这意味着你不需要在几十个国家注册税号、也不用处理增值税（VAT）和销售税的申报，MoR 会统一代收代缴后再把净额结算给你。代价是费率通常高于纯支付处理商（如 Stripe 的 2.9% + 30¢），因为其中包含了税务与合规服务。Stripe 本身不是 MoR（Stripe Tax 只帮你计算和收取，申报仍由你负责），所以选择本质上是“用费率换合规负担”的权衡。

工具化思路与适用边界

Deepak 把自己踩过的坑写成了可供 Claude Code、Cursor、Codex 遵循的指令文件（skills），做成了 ShipToPaid。与其指望 AI 助手每次记得校验密钥戳、忽略迟到消息，不如输入一句“/add-paywall add payments to my app”，让它按已经写好这些陷阱的步骤执行，随后再用一份上线审计清单走一遍。

想先试水的话，GitHub 上有一个免费精简包，包含三个技能：Polar 结账、Polar 支付消息、一份简短上线检查。完整版增加了 Stripe、支付驱动的权限管理、客户账单页、额度、许可证密钥、五个现成命令和一个可运行的 Next.js 起步应用。每个技能都是可直接阅读和修改的纯文本文件。

不用这套工具也完全可以照本文操作：在测试模式跑完清单，修掉所有失败项，你的第一位付费客户就能拿到他付钱买到的东西——这就是全部目标。

从更宏观的角度看，AI 编程把“做出功能”的门槛压得很低，但支付、权限、税务这类涉及真实金钱和真实法律义务的环节，恰恰是 AI 最容易想当然的地方。把 AI 当作写得快但需要验收的施工队，而不是可以免检的承包商，是目前更稳妥的协作姿势。