构建自有计费系统的痛苦

计费是自建还是采购

• 普遍共识是：计费看似简单，实际上极其复杂；很多人认为大多数公司不应该自建，而应使用 Stripe/Braintree/Chargebee/Lago/killbill 等。
• 反方观点：对于简单产品或早期阶段，可以先从小处做起，逐步构建，并接受一些人工操作；“永远不要自建”的过度泛化建议被认为言过其实。
• 另一种观点：如果计费是你业务的核心，或者你所在地区主流服务商无法使用（例如某些非美/欧司法辖区），那就应该自建。

复杂性与隐藏边界情况

• 真正的痛点在于长尾问题：按比例分摊规则、升级/降级、祖父条款、试用期、定制企业合同、联盟分成、退款/拒付，以及把整个流程“反向执行”（积分、修正、部分退货）。
• 时区、不同计费周期、预付与后付计费、按用量定价、分级折扣和四舍五入行为都会以不明显的方式相互影响。
• 许多自研系统因为舍入错误、扩展性问题，以及脆弱的“胶带式”逻辑而造成巨大的财务损失。

权益与计费

• 强烈建议将计费（资金、发票、收入确认）与权益（客户实际可用的内容）分离。
• 建议的架构：权益系统存储能力/限额；计费系统计算费用；一个独立的策略层把两者连接起来，并支持一次性调整和人工微调。
• 关于使用 feature flags 作为权益系统的讨论：它很方便也很灵活，但有把一个系统负载过重的风险；有些人更偏好专门的权益/授权服务。

安全、合规与监管

• 围绕“把文件扔进 S3 + cron”的想法展开讨论：有人认为这很天真，但技术上可以做得很稳健；传输中/静态加密是标准做法，但可能无法满足更严格的威胁模型。
• 有人认为只有使用独立密钥的客户端侧加密，才真正符合“静态加密”的初衷。
• 关于欧盟规则的互相矛盾说法：多人澄清，自建计费是允许的；监管主要针对支付处理和 PSD2 流程，而不是内部发票系统。

会计、税务与法律问题

• 与会计/ERP、收入确认、在途资金对账、月/季度结账以及审计可追溯性的集成，是巨大的负担。
• VAT/销售税、各国不同规则、更正发票、单据编号和留存要求被描述为令人精疲力竭但又必须做到的事情。
• 错误可能导致罚款甚至更糟；你必须能够解释“为什么这个客户支付了这个金额”。

工具与平台

• Stripe 因让支付变得简单而受到称赞，但也被批评 API 令人困惑、高层抽象薄弱，以及存在运维缺口（webhook 丢失、状态同步）。
• 还提到了一些开源和商业计费平台（例如通用 OSS 引擎、按用量计费初创公司、merchant-of-record 服务）作为可选方案，不过价格不透明是常见抱怨。

设计模式与反模式

• 推荐的模式：清晰的职责分离（权益 vs 分类账 vs 开票）、基于账本的会计、定时流程而非实时耦合、幂等操作、可配置的舍入规则。
• 反模式：单体式“计费大块”、将权益与支付紧密耦合、到处都是实时副作用，以及无法扩展的天真状态机历史记录。

轶事与态度

• 故事包括保险公司寄来的“魔法钱”支票、混乱的医疗应收账款对账、变得无法维护的旅游和电信系统，以及一个小型成功案例：自定义计费解锁了灵活的支付方式。
• 几位经验丰富的工程师把计费比作“化粪池管道”：令人不快、有风险、常被低估，但技术上很有意思，而且始终有需求。