Vibe-Coded应用如何收费：一次性买断还是订阅制？

你用Claude Code、Cursor或Codex构建了一个应用，已经有用户在用，甚至有人表示愿意付费。这时你面临两个问题：该怎么收费，以及如何在不搞砸的前提下完成支付接入。本文作者Deepak是海得拉巴的一名独立开发者，他为许多AI智能体构建的应用接入了支付系统。以下是他的经验总结。

Vibe-Coded应用收费指南

三种主流收费模式

几乎所有小型应用都采用以下三种模式之一，或混合使用：

一次性买断：客户付一次钱，永久使用。适合模板、工具、终身授权或可下载资源包。
订阅制：客户按月或按年付费，停止付费即失去访问权限。
积分制（按使用量付费）：客户购买一笔使用额度，比如100次图片生成，用完后再次充值。

没有"正确答案"。合适的选择取决于一个简单问题。

决定收费模式的关键问题

你的应用每次被使用都会产生成本吗？

如果答案是肯定的，你大概率需要订阅制或积分制；如果是否定的，一次性买断往往更简单、也更容易成交。

原因在于，许多vibe-coded应用会调用AI模型、发送邮件、存储文件或运行在按使用量计费的服务器上。只要客户继续使用，这些成本就会持续产生。如果你只收一次钱，重度用户最终可能让你倒贴。而按月收费或积分耗尽的机制，能让你的收入与支出保持匹配。

如果你的应用主要是固定形态的产品，比如计算器、模板、桌面工具或一组文件，成本不会随用户数量显著增长，那么一次性收费既诚实又容易让买家点头。

一次性买断：适用场景与注意事项

适合： 运行成本较低的工具、模板和启动套件、可下载产品，以及"终身访问"的发布优惠。

买家喜欢的原因： 不必担心又多一笔月度账单，解释起来简单，也没有什么需要取消的。

隐患： 你只收一次钱。要持续获得收入，你需要稳定的新买家流，或者后续推出付费升级。尤其要小心那些调用AI模型的应用搞"终身"优惠，因为成本并不会停止。

需要配置的内容：

在支付平台后台创建一个单一价格的产品。
一个"购买"按钮，将用户引导至支付平台的结账页面。
你的应用监听支付消息（开发者称之为webhook，即支付平台自动发来的"此人已付款"通知），并将该用户标记为买家。
付费页面在放行前检查"此人是否为买家"。

就这么简单。没有续费、没有取消，只需处理退款。

Webhook 与验证：支付平台（如 Polar 或 Stripe）在交易状态变化时，会向你在应用中配置的 URL 发送一个 HTTP POST 请求，这就是 webhook。它携带事件类型（如 payment.succeeded）和签名头。你的应用必须使用平台提供的密钥（webhook secret）验证签名，确保请求确实来自支付平台，而非伪造。验证通过后，再解析事件并更新用户权限。忽略验证会让攻击者有机会伪造“已付款”通知，免费获得访问权限。

订阅制：适用场景与隐藏复杂度

适合： 用户会定期使用的应用、有持续成本（AI、托管、数据）的应用，以及你持续改进的应用。

开发者的理由： 每月重复的收入，更容易做规划，也更容易持续支付服务器费用。

隐患： 环节更多。用户会取消、信用卡会过期、支付会失败，有些客户还会在套餐之间切换。你的应用必须对每一种情况做出正确反应，而不仅仅是首次付款。而且买家在注册一个永久扣费的服务时会更加谨慎。

需要配置的内容：

一个按月定价的产品，可选加一个按年定价（通常提供折扣）。
一个"订阅"按钮，跳转至结账页面。
你的应用监听支付消息，不仅是"已付款"，还包括"续费成功""已取消""支付失败"和"已退款"，并在每次事件时更新用户权限。
付费页面检查"此订阅当前是否有效"。
一个"管理账单"页面，让客户可以自行更换信用卡或取消订阅。Polar和Stripe都提供现成的页面，无需从零构建。

第3步是大多数AI生成的支付方案容易出错的地方。智能体处理了首次付款，却忘了后续事件，导致已取消的用户永久保留访问权限。作者的上一篇博客中有一份检查清单可以用来排查这个问题。

订阅生命周期事件：订阅不仅仅是“首次付款”，还包括续费成功（invoice.paid）、续费失败（invoice.payment_failed）、取消（customer.subscription.deleted）、退款（charge.refunded）等。每个事件都需要你的应用相应地调整用户访问权限。例如，收到取消事件后，应设置一个到期时间，而不是立即撤销访问，直到当前计费周期结束。支付失败时，可以给用户一个宽限期并发送提醒邮件。正确处理这些事件是避免收入损失和用户纠纷的关键。

积分制：折中方案

如果你的成本高度依赖用户的使用量，积分制可能比前两种都更公平。客户购买一包额度，每次使用扣除一定数量，额度低时再充值。轻度用户花得少，重度用户花得多，你永远不会在单个人身上亏钱。

代价是：你的应用必须为每个用户维护准确的余额，并且绝不允许余额变为负数，即使用户快速点击两次也不行。这完全可行，但需要仔细测试。

原子性与并发控制：积分扣减必须保证原子性，即检查余额和扣减余额作为一个不可分割的操作。如果两个请求同时到达，都先读取余额为 1，然后各扣 1，余额就会变成 -1。解决方法包括使用数据库的原子操作（如 UPDATE users SET credits = credits - 1 WHERE id = ? AND credits >= 1 并检查影响行数），或使用事务和行级锁。在分布式系统中，还可以借助 Redis 的原子递减命令。测试时务必模拟并发请求，确保余额不会为负。

拿不定主意？从简开始

如果无法决定，以下是一个合理的默认方案：

低运行成本： 从一次性定价开始。之后可以增加订阅层级。
有真实运行成本（如AI调用）： 从一个月度套餐开始。只设一个。等用户提出需求后再加年付选项或第二层级。

无论选哪种，你都可以改变。你的第一个价格只是猜测，这没关系。真实客户会比任何定价文章告诉你更多。

Polar与Stripe：独立开发者怎么选

确定收费方式后，你需要一个支付服务商。对大多数独立开发者来说，选择集中在Polar和Stripe之间。两者都能很好地处理一次性付款和订阅。

Polar是记录商户（merchant of record）。通俗地说，Polar在纸面上是卖家：它负责在你客户购买的国家收取并缴纳销售税和增值税，然后将款项支付给你。如果你独自面向全球销售，这能省去大量文书工作。代价是每笔交易的费率高于Stripe的基础费率，建议查看其当前定价页面。

Stripe处理支付，但你是卖家，税务是你的责任。Stripe有一个税务附加组件可以计算出正确的征收金额，但注册和申报仍然由你负责。作为回报，你获得更多控制权和庞大的功能集。

作者的经验法则： 如果你是独立开发者，向多个国家销售数字产品或订阅，且不想操心税务，从Polar开始。如果你已经有Stripe账户或已有处理税务的业务实体，用Stripe。无论选哪个，先确认它能否向你的国家付款。如果税务让你头疼，花点钱咨询会计师是值得的。

记录商户（Merchant of Record, MoR）：MoR 是法律上的卖家，负责处理销售税、增值税（VAT）等税务合规。对于向全球销售数字产品的独立开发者，不同国家的税率和申报规则极其复杂。Polar 作为 MoR，会代你计算、收取并缴纳相应税款，你只需接收净额付款。这大大降低了合规门槛。而 Stripe 是支付处理商，你才是卖家，税务责任自负。Stripe Tax 可以帮你计算税额，但注册和申报仍需自己完成。选择 MoR 相当于用略高的费率换取税务外包。

分步接入指南

无论你的应用是用Next.js（vibe-coded Web应用最常见的配置）还是其他技术栈构建，以下步骤都适用。你会让AI智能体完成大部分工作，但检查的责任在你。

创建账户：在Polar或Stripe注册，并保持在测试模式（不涉及真实资金的练习模式）。
创建产品和价格：在后台设置一次性、按月或两者兼有。
让智能体添加结账功能。指令要具体："添加一个订阅按钮，将已登录用户引导至我的Pro月度产品的Polar结账页面。"
让它处理支付消息，并列出所有类型：已付款、续费、取消、支付失败、退款。要求它使用后台的密钥验证每条消息的真实性。
让它锁定付费页面，确保页面检查的是数据库中的访问权限，而不仅仅是用户是否看到了感谢页面。
添加账单页面，让客户可以自行取消或更新信用卡。
用测试卡测试一切：购买、登出再登录、取消、退款，并以免费用户身份尝试账单页面。
切换到实时模式，复制实时密钥，自己完成一次真实购买，然后退款。

第7步是大多数人会跳过的，也正是它能帮你避免愤怒的客服邮件。

一站式方案：ShipToPaid

作者厌倦了手动编写这些提示词并反复修复同样的错误，于是将经过测试的步骤转化为书面指令（称为skills），供Claude Code、Cursor和Codex遵循。这就是ShipToPaid。

你不再需要执行上述第3到第6步，只需在智能体中输入/add-paywall，说明你想要一次性还是订阅制，它就会按照一份已经覆盖各种陷阱的检查清单执行：验证支付消息真实性、处理取消和支付失败、正确锁定付费页面。发布审计功能会引导你完成测试。

想先试试？GitHub上的免费精简包包含Polar结账、Polar支付消息和一份简短的发布检查清单。完整包增加了Stripe、控制访问的订阅、客户账单页面、积分、许可证密钥和一个可运行的Next.js起始应用。每个skill都是你可以阅读和修改的普通文件。

你也可以完全不使用这些工具来遵循本指南。选择收费方式，选择支付服务商，在测试模式下走通整个流程，然后去获取你的第一个付费客户。