01
2 个月，我做成了一个集成支付与消费的变现系统，完全不在预期，真的。
1月底，第一个项目收尾的时候，我问了自己一个问题，"除了积分制，SaaS到底还有哪些定价模式？"
就是这一个问题，开了一个我没想到的口子。
02
我去看优秀案例，一个一个拆解，最后分析出了 4 种收入模式——买断制、无限订阅、纯积分制、配额订阅（订阅+积分），这几乎涵盖了市面上 95% 的小而美的 SaaS 模式。
然后我就在想，"我能不能把这4种都做完？后续做新项目，一个配置切换定价模式，改改文案和价格，直接上线了？"
只是想到这里，就觉得激动了。
以我多年的开发经验，这件事 8，9 成能做。那说做就做。
03
但做着做着才发现，水比想象的深。
creem，paypal 能创建试用产品，可是无法入参让它变成不带试用的，这样就会让用户无限使用，甚至在试用前取消，都有可能是吧，而这是直接影响收入的。
订阅的升降级，PayPal 官方的升降级逻辑有个漏洞——升级套餐在下个周期才扣款。
也就是说，用户今天升级 Pro，明天就能用 Pro 的功能，但钱要下个月才收。更离谱的是，他完全可以在扣款前一天取消，白嫖十几天的 Pro 权限，你一分钱收不到。
如果不知道这个规则，服务送出去了，钱没进来，你甚至都不知道哪里出了问题。但也必须采用一个折中的方法，因为，你总不能完全禁止用户去选择更好的套餐吧，对吧，方案也要定。
积分消耗的顺序，先消耗订阅积分，还是购买积分？顺序不同，用户体验完全不同。
每一个决策背后，都是大量的思考和测试。
这些，AI 确实帮我写了大量的代码，但是有些绕一点的逻辑，它也给不了最佳答案。只能自己想，自己推演，验证，但终究，做成了，用户体验也很不错。
而这些，也才是真正花时间的地方。接支付不难，难的是每一个，"如果用户这样操作了怎么办？我是否处理好了？"
这些边界场景，我一个一个处理完了——
升级套餐立即生效，降级等当前周期结束；取消了保留权限到期；重复订阅不重复扣费；赠送积分过期自动扫描；并发消费数据库原子操作，不会扣超，等等……
16+ 个场景，全部走通了。
真的 0 代码，只需要改配置文件，即可改定价模式、修改套餐。
# 定价模式 (Pricing Models)
## credits - 按量购买（可以是积分、流量、API 调用、Token、请求次数等，形态由产品决定）
## subscription_unlimited - 订阅制，订阅期间无限使用（可含试用期）
## subscription_quota - 订阅制，每期含固定用量，可额外购买
## lifetime - 买断，一次付费永久访问
NEXT_PUBLIC_PRICING_MODEL=subscription_quota
# 修改套餐
const SUBSCRIPTION_PLANS = {
basic: {
priceMonthly: 9.99,
priceYearly: 99.99,
priceMonthlyCNY: 29,
priceYearlyCNY: 299,
name:
'Basic',
features: [
'xx'],
quota: 100 ... },
pro: {
priceMonthly: 29.99,
priceYearly: 299.99,
priceMonthlyCNY: 99,
priceYearlyCNY: 999,
name:
'Pro' ...
}但光做完支付还不够。还有消费。
用户订阅了，怎么判断权限？不同定价模式，权限是不一样的。
交付呢？也不一样，像代码类这种买断制的交付，也根本不在网站上。
还有配额订阅，不只是订阅积分，还有赠送积分，还有购买积分，这些都要一一做好。
如果每个项目都要重新写一遍消耗逻辑，那这件事就没有真正闭环。
所以当然是要抽象出来，不硬编码，我又重新设计，把积分消耗、权限控制、状态管理全部封装好，只暴露一个方法，调用就行。
最终，判断权限一个方法，消费一个方法，嗯，够干净，也够用，不是么。95％ 的 SaaS ，且无论什么形态的 SaaS ，无非就是判断权限和消耗积分，没有别的，写作/图片/视频等等，本质都是消耗，个数，次数也好，都可以叫做积分消耗。
// 判断用户权限
useService(
'use')
// 判断权限、消耗积分
useService(
'consume'
, 9)04
支付方式呢？
考虑到国内外手续费的问题，我算过——买国内域名、服务器、备案的成本，远低于走国际通道的手续费损耗。所以国内单独接支付宝，国外走 Creem 和 PayPal 。
Stripe 也接了，虽然现在还没有生产账号，但早做好，后续就不用再为支付分心了啊，是吧。 最终也是一个配置。
# 支付方式 (Payment Providers)
## 可选: alipay, creem, stripe, paypal — 逗号分隔，控制 pricing 页面显示哪些支付按钮
## 未配置时，.cn 站默认 alipay，国际站默认 creem,paypal
NEXT_PUBLIC_PAYMENT_PROVIDERS=creem,paypal
# creem 配置...
# paypal 配置...也就是想用这个系统，有多么简单？
整体，在支付上，0代码，只需要改配置；在用户权限控制、消费上 2 行代码，就轻松搞定了。
最终，4 种定价模式 × 4 种支付方式，全部跑通，这的确是我在刚开始没有想到的，这就是 Pay4SaaS ，有了它，无论是 AI 写作，绘画，视频生成等等这些 SaaS，都可以轻松闭环变现了。
那整体搭好这个系统，花了多久？300+ 小时。而且是在极度专注、踩了无数坑、反复推翻重来的前提下。如果你也从零搭，大概率不止这个数。
05
不过这样，也才真正算是一个完备的变现基础设施啊。
为什么我非要把支付和消费做透呢？
因为我从开始，就想得很清楚——如果现在随便做做，后续每个新项目都要补坑，补完还要兼顾前面的项目，处理不完的琐事。维护过多个项目的人，应该都体会过这种噩梦。
我做独立开发，就是为了时间自由，能够脱离出这些琐事，去做更有价值的事情。 一个能赚钱的 SaaS = 核心功能 + 变现闭环（支付 + 权限控制+ 消费）。 如果这个事做不好，自由就是空话，甚至会成为生活中的一个时不时冒出来的困扰，这，不是我想要的。
所以，做好收钱+让有权限的用户正确地消费，是做一个 SaaS 的前提，300 多个小时踩过来的坑，你不用再踩了。