AI SaaS 的 credits 计费，最先决定的不是「一个 credit 卖多少钱」，而是谁当记录商户、谁处理客户发票、谁承担间接税、谁能解释月底那张账单。这个顺序错了，后面再漂亮的 pricing table 都会变成客服和财务问题。
一个人做 SaaS，通常先撞上两个现实限制：团队没有专职财务工程师，也不想第一版就自己维护多国家税务注册。2026 年 5 月 24 日查看官方文档后，默认推荐给 Polar；例外是你已经深度接入 Stripe，并且能自己处理 Stripe Tax、Credit Grant、meter event、invoice finalization 和财务报表。
先选谁？
| 你的状态 | 默认选择 | 原因 |
|---|---|---|
| AI wrapper、开源工具、个人 SaaS 第一版 | Polar | MoR、订阅、meter、credits、发票和 payout 在一个更窄的产品限制里 |
| 已经用 Stripe Checkout / Billing 收费 | Stripe Billing | 复用已有 customer、subscription、invoice、tax 和 webhook |
| 有欧盟、英国、美国多州客户，但没有税务注册能力 | Polar | Polar 作为 MoR 处理客户交易层间接税，开发者只拿平台结算 |
| 企业合同、PO、复杂发票、Sales-led B2B | Stripe Billing 或合同外置 | Stripe 的订阅、invoice、quote 和报表组合更灵活 |
| 只卖充值包，不想做订阅 | 谨慎用 Stripe credits | Stripe billing credits 主要贴着 metered subscription items，不是通用储值钱包 |
| 产品含人工服务、代运营、撮合交易或高风险内容 | 两边都先停 | MoR 和支付平台都可能要求额外审核或拒绝 |
这张表不是说 Polar 永远简单、Stripe 永远重，而是第一版 AI SaaS 该先处理税、发票、退款、争议和 credits，再来谈复杂账单模型。
MoR 和 Stripe Billing 的限制在哪里？
Polar 的 Merchant of Record 文档把限制写得很直：Polar 作为 reseller / MoR，承担国际 sales tax 这类交易层责任，开发者把数字产品卖给 Polar，再由 Polar 面向终端客户销售。客户看到的发票、税、退款和争议，进入 Polar 的交易链路。
Stripe Billing 是另一层东西。它负责 subscription、invoice、metered usage、credit grants 和 customer balance 这些账单对象。它不自动把你变成「不用管税的卖家」。Stripe Tax 可以帮你监控、注册、计算、收取、报告和通过伙伴申报，但 Stripe Tax 文档也明确把 tax compliance cycle 拆成理解义务、注册、计算收取、报告申报和汇缴。
Stripe pricing 页里还有 Managed Payments，定位是 Stripe 的 merchant of record solution，费率口径是每笔成功 Managed Payments transaction 额外 3.5%，并且在 Payments fees 之外。这个信息反而说明了重点：Stripe Billing、Stripe Tax、Stripe Managed Payments 是不同产品，不要在架构图里画成一个按钮。
| 责任项 | Polar | Stripe Billing | Stripe Tax / Managed Payments |
|---|---|---|---|
| 订阅和用量账单 | 支持 subscription product、metered price、Meter Credits | 强，支持 subscription、Meters、Credit Grant、invoice | Tax 不负责账单模型；Managed Payments 是 MoR 层 |
| 记录商户 | Polar 作为 MoR / reseller | 不是 MoR | Managed Payments 才是 Stripe 的 MoR 方向 |
| 销售税、VAT、GST | Polar 承担交易层间接税处理 | 你仍是商户责任主体 | Tax 帮计算和申报流程；MoR 才改变记录商户 |
| 发票抬头 | 客户面对 Polar 链路 | 客户面对你的 Stripe 商户主体 | 取决于 Tax 或 Managed Payments 产品 |
| 争议和退款 | Polar 参与处理，并有 review / chargeback 规则 | Stripe 提供工具，你自己负责策略 | Managed Payments 才会更多接管责任 |
| 所得税、公司税、本地申报 | 仍归开发者或公司 | 仍归开发者或公司 | 仍要看主体、司法辖区和会计意见 |
这不是法律或税务建议。真正上线前，要把公司注册地、税务居民身份、客户所在地、产品类别、发票要求和银行入账材料给会计看。MoR 减少的是客户交易层的税务和争议负担，不会替你完成公司层面的纳税、年报、分红或个人申报。
credits 计费模型怎么拆？
AI SaaS 最常见的错误是把 token、credits、套餐、余额和发票混成一个字段。正确做法是拆成 5 层：用户看 credits，系统记 meter events，账单按 subscription item 出 invoice，税务按交易链路处理，财务按 payout 或 Stripe balance 对账。
| 模型 | 用户看到什么 | 后台计量 | 适合产品 | 主要风险 |
|---|---|---|---|---|
| 固定订阅 | Pro $19/月 | 不计或只做风控日志 | 成本极低、用量差异小的工具 | 重度用户吃掉毛利 |
| 固定订阅 + credits | Pro 每月 2,000 credits | meter event + cycle grant | AI 写作、图片生成、语音转写 | credits 和 overage 文案不清 |
| 预付 credits | 购买 $100 credits | credit ledger + meter | API、批处理、企业预充值 | 可能被用户理解成钱包或储值 |
| Pay as you go | 用多少付多少 | meter event → invoice | 成熟 API、B2B 技术产品 | 新用户害怕账单失控 |
| 固定费 + overage | 包 10 万 tokens，超出按量 | threshold + metered price | 已有稳定用量分布的 SaaS | 首月、退款、升级后对账复杂 |
Polar usage-based billing 的核心链路是 events、Meters、metered prices 和 Meter Credits benefit。官方例子直接用了 AI LLM tokens：应用发送 ai_usage 这类 event，meter 聚合 total_tokens，subscription product 里的 metered price 再产生计费。Meter Credits benefit 可以在每个订阅周期开始时给某个 meter 发放 units。
Stripe 的 billing credits 走 Credit Grant 账本，更适合把 credits 做成预付或促销余额。它的强约束也要写进产品文案：credit grants 只能应用到使用 Meters 的 metered subscription items，不能应用到 one-off invoices、licensed prices，也不支持 legacy Usage Records。Stripe 文档还写了 unused credit grants 的上限：每个客户最多 100 个。
Polar 的优势是什么？
Polar 的优势是「窄而快」。对 AI SaaS 第一版来说，窄不是缺点。你要卖的是软件访问、订阅、license、下载权益、API 或 credits，而不是立刻搭一套 Stripe + Tax + Revenue Recognition + 自建 admin 的财务系统。
Polar pricing 在 2026 年 5 月 24 日比对时，Starter 为 5% + $0.50；Pro 为 $20/月加 3.8% + $0.40；Growth 为 $100/月加 3.6% + $0.35；Scale 为 $400/月加 3.4% + $0.30。非美国 international cards 另加 1.5%。争议费是 $15，不论结果都会从余额扣除。
还有一个时间点要单独记：2026 年 5 月 27 日前创建的 organization 保留 Early Member 口径，页面写的是 4% + $0.40，subscription payments 另加 0.5%。一旦升级到 paid plan，Early Member 会退出，之后再降级回 Starter 会落到新的 Starter 费率。
| Polar 项 | 对 AI SaaS 的意义 | 上线前要确认 |
|---|---|---|
| MoR | 少处理客户交易层税务、发票和争议 | 产品是否在 acceptable use 里 |
| Usage events | 记录 token、图片、语音分钟、文件处理量 | event name、customer id、metadata 是否稳定 |
| Meters | 把原始事件聚合成账单数量 | filter 和 aggregation 是否能解释 |
| Metered price | 给 subscription product 绑定按量价格 | 只适用于订阅产品 |
| Meter Credits | 每周期给客户发放 meter units | credits 用完后是否允许 overage |
| Account review | 首次 payout 前可能审核 | KYC、网站、产品、webhook、payout 账户要齐 |
Polar 也不是无审核通道。Account reviews 文档写明，首次 payout 前会做主账户审核，包含业务说明、KYC 和 Stripe Connect Express payout account；初审可能最长 14 天。连续审核会看 acceptable use、refunds、chargebacks 和 risk score；Polar 的 chargeback 管理目标是 0.4%，低于卡组织把 0.7% 以上视为 excessive 的阈值。
Stripe Billing 赢在哪里？
Stripe Billing 赢在「可组合」。如果你的 SaaS 已经有 customer、subscription、invoice、tax ID、coupon、quote、Customer Portal 和 accounting export，Stripe Billing 的 credits 就能嵌进现有系统，而不是迁到另一套 MoR 后台。
Stripe 的 credit-based pricing model 示例是 LLM：input token 和 output token 分别建 meter，price 绑定 meter，subscription 里挂多个 usage-based prices，再给 customer 创建 Credit Grant。Stripe 还提醒：billing_mode=flexible 创建订阅时，首张 invoice 会排除没有历史 usage 的 metered line items；invoice finalized 后，适用的 billing credits 才会自动应用。
这两个细节很关键。第一，Stripe credits 不是实时余额体验的天然答案，文档里的操作步骤是在 invoice finalization 时应用；高级实时 burn down 还在 private preview。第二，meter event 异步处理，upcoming invoice 可能不会立刻反映刚发送的事件。AI SaaS 如果给用户做实时 credits UI，仍要有自己的 usage ledger。
| Stripe 组件 | 适合解决什么 | 不适合误解成什么 |
|---|---|---|
| Meters | 聚合 token、request、storage、job 等用量 | 客户可读的唯一实时余额 |
| Credit Grant | 预付或促销 billing credits | 礼品卡、通用储值或第三方支付余额 |
| Subscription items | 把多个 usage price 放进同一订阅 | 任意一次性 invoice 的 credits 抵扣入口 |
| Invoice finalization | 最终应用 credits 和生成账单 | 实时扣点系统 |
| Stripe Tax | 计算、收取、报告和辅助申报税 | 自动把你变成 MoR |
| Managed Payments | Stripe 的 MoR 方向 | Billing 默认能力 |
Stripe pricing 页在比对日显示，Billing pay as you go 是 0.7% of Billing volume，包含 Stripe 内外处理的 Billing transactions，不含 one-off invoices。Stripe Tax 的 no-code / low-code 价格口径以 active registration 和 live transaction 计算，pricing 页同时展示了 Tax 的独立产品区。预算时不能只拿 0.7% 对比 Polar 5% + $0.50，因为这两者覆盖的责任范围不一样。
成本表怎么做才不会误判？
用 1,000 个 Pro 用户来做预算很诱人，但第一版 AI SaaS 更该用三种订单形态算：小额月付、年付订阅、企业预付。固定费用、国际卡、Tax、refund、chargeback 和 payout 都会改变结论。
| 费用项 | Polar | Stripe Billing |
|---|---|---|
| 账单系统费用 | Starter 5% + $0.50；付费计划降低变量费率 | PAYG 0.7% of Billing volume |
| 支付处理 | Polar 底层支付成本已进入 MoR 口径，另看 payout provider fees | 还要叠加 Stripe Payments 等费用 |
| 国际卡 | 非美国 international cards +1.5% | 常见 Stripe Payments 国际卡另算，按账户地区比对 |
| 税务 | MoR 处理客户交易层间接税 | Stripe Tax 单独计费，注册、申报、汇缴仍要管理 |
| 争议 | $15 per dispute；chargeback rate 有审核阈值 | Radar、dispute、证据和退款策略自己配置 |
| 财务对账 | payout、reverse invoice、订单和税额看 Polar 链路 | invoice、balance transaction、tax report、Revenue Recognition 可组合 |
| 迁移成本 | 从 MoR 迁出要处理发票历史、权益和客户解释 | 留在 Stripe 生态内迁移更轻，但税务责任更重 |
如果你的客单价是 $9/月，Polar 的固定 $0.50 会很疼；如果你的客户分散在多个税区，Stripe 的低 Billing 费率又可能被税务注册、申报和人工成本吃回去。小额 B2C 和开发者工具要看「每笔固定费」；高客单 B2B 要看「发票、采购、税号和合同」。
设计 AI credits 时先写这 7 个字段
不要先开后台建价格，在自己的数据库里写清楚这 7 个字段，再决定 Polar 还是 Stripe Billing。
| 字段 | 示例 | 为什么重要 |
|---|---|---|
usage_event | ai_completion_finished | 以后所有 meter 都从这里来 |
external_customer_id | 你的 user id 或 workspace id | 平台账单要能映射到内部客户 |
meter_unit | total_tokens、image_count、audio_minutes | 决定账单怎么聚合 |
display_credit | 1 credit = 1,000 tokens | 决定用户能不能看懂 |
cycle_grant | Pro 每月 2,000 credits | 决定订阅价值感 |
overage_policy | 用完停用或按量收费 | 决定投诉和退款风险 |
ledger_source | Polar / Stripe / internal | 决定谁是最终账本，谁只是展示 |
Polar 更适合把 cycle_grant 贴近 subscription benefit；Stripe 更适合把 ledger_source 做成 Credit Grant 和 invoice 账本。无论选哪边，都不要把平台后台当唯一审计流水。客户问「为什么今天扣了 83 credits」时，你要能回到 request id、模型名、输入输出 tokens、时间戳和扣费规则。
后台怎么管才不乱？
usage-based billing 上线后，后台会同时出现 Polar 或 Stripe、OpenAI / Anthropic、数据库、GitHub、Cloudflare、银行、客服邮箱和会计软件。真正出事故时，常见原因不是 meter 少写一个字段，而是有人改了 price、coupon、tax code、webhook 或 model mapping，却没有留下变更记录。
如果团队分布在不同城市，建议把收款、模型供应商、部署和财务后台放进同一套登录规范：固定负责人、固定设备、固定 2FA、月度导出、变更单和退款记录。核心后台可以用海外银行 + Stripe + AI 工具全场景承载，重点是让收款、部署和 AI 供应商账号保持可追溯的操作环境。
这段不是在给计费系统加玄学配置。AI credits 的事故要能从「客户看到余额变化」一路查到「模型供应商扣了多少 token」。登录环境、变更记录和导出节奏越稳定，月底对账越少靠回忆。
未覆盖的限制
这篇只比较 Polar 与 Stripe Billing 在 AI SaaS credits、usage-based billing、MoR 和税务限制上的产品选择，不替代律师、CPA、会计师或税务顾问意见。
以下 5 个限制不在覆盖范围内：
- 没有判断你的公司注册地该在哪里。
- 没有判断你是否已经触发某个国家或州的税务注册义务。
- 没有测试 Stripe Managed Payments 的实际准入和地区可用性。
- 没有覆盖所有 Polar acceptable use 高风险类别。
- 没有替你判断 AI 生成内容是否涉及版权、商标、肖像、成人内容或监管风险。
Polar acceptable use 页面在 2026 年 3 月 25 日生效的版本里，把 Software & SaaS、数字产品、premium content & access 列为可接受产品，同时也列出 physical products、human services、marketplaces、成人内容、金融服务、部分 AI 内容生成工具等限制或禁止类别。AI SaaS 不是写了「SaaS」就自动安全；产品能力、交付方式、客户群和营销文案都会影响审核。
落地顺序
第一版 AI SaaS，我会按这个顺序做：
- 用内部 usage ledger 记录每次模型调用。
- 把前台单位定成 credits，不直接暴露复杂 token 价格。
- 如果没有税务和财务人手，用 Polar 跑 subscription + meter + credits。
- 如果已有 Stripe 生态，用 Stripe Meters + Credit Grant 做测试账单。
- 用 3 个测试客户跑新订阅、用完 credits、overage、退款、取消、发票和 payout。
- 把 tax、invoice、refund、chargeback 和 support 脚本写成客服能读懂的话。
- 月底导出订单、用量、credits、税额、平台费和银行入账，交给会计复核。
Polar 的默认价值是让独立开发者少背一层交易责任，Stripe Billing 的默认价值是让成熟 SaaS 拥有更细的账单控制。不要把「费率低」当唯一答案。AI SaaS 的 credits 计费，最终比的是谁能让客户、后台、发票、税务和会计在同一套数字上说话。