构建计费系统的 14 个痛点！
计费最初是一个工程问题，根植于一个非常非常复杂的问题空间，即使是业内资深人士也很难理解。本文作者分享了 14 个其在自建计费系统时必须要考虑的难题。
原文：https://arnon.dk/the-14-pains-of-billing/
作者 | Arnon Shimoni
翻译工具 | DeepL 责编 | 苏宓
出品 | CSDN（ID：CSDNnews）
如果你计划从业务中获利，计算和收入系统是必不可少的。
如果你以前接触过这些系统的研发，你就会知道计费系统非常复杂，没有人愿意去考虑它们。但是当它们发挥作用时，大家又会非常开心。
我曾看到有人将它们比作章鱼，我完全同意。它们涉及财务、产品、体验、客户支持、客户、法律、合规、销售，有时甚至更多。
计费是一项艰巨、错综复杂的工作。
由于它是相互关联的，一旦出现问题，就会带来不小的麻烦。而且这类的系统的确会经常出问题。(如果你有一个团队在维护这个系统，但不是你，那就问问他们！）。
另外，如果你的系统还没有崩溃，给它一些时间。
我知道你忙于经营业务，你的事情已经很多了。你只想收点钱，然后继续开发对客户来说更重要的功能。
但请记住：
如果你不能合法、正确地收款，这将成为一直困扰你的问题，也会让你有更多的事情要处理。
三种模式
这并非计费系统独有的现象。常见的有三种模式，当然，这三种模式各有利弊：
- 自建系统：完全自主研发的解决方案。完全可控、完全可定制，而且你无需向外部任何人支付费用。许多人认为（许多公司都这样认为），建立和维护自己的计费系统是企业的最佳选择。
- 完全第三方系统：所有业务逻辑、付款处理、开票、税务合规、使用、计量--全部由一个全方位服务解决方案完成。这对公司来说很方便，但你会失去很多控制权，而且可能要花很多钱才能达到这个目的。
- 自建系统和第三方系统的混合系统：本地解决方案与第三方解决方案相结合。例如，你的计费引擎是内部的，支付由 PSP 处理，税务合规由税务 SaaS 处理。在这种情况下，你可以控制业务逻辑（例如，何时更新数量），但逻辑由第三方处理。
刚成立公司时（或刚开始开发新产品时），一切都要靠自己，这是很自然的。
你有工程师。你希望一切从简。有这样的想法很正常，因为你往往还在像工程师那样思考。
你把计费当成一个工程问题。你会对自己说：“为什么我们不能把需要计费的文件转存到 S3 上，然后让 CRON 作业接收并收款呢？”
但你错了。这是一个非常棘手的大问题，只是你还没有意识到而已。
以下是我对典型计费团队需要担心的问题的高级描述（见仁见智）：
一个典型的计费或货币化团队有很多职责，即使是经验丰富的专业人士也很难把握。
每个人都知道，安全（或日期处理）不是你一个人的事。你也不应该自己从头开始做一个计费系统。
构建自己计费系统的 14 个痛点
接下来，我会列出一些我在使用自制计费系统时遇到的一些问题（从简单到复杂）：
1. 幂等性（Idempotency）。所有计费、收款请求都必须是唯一和不可篡改的。当你达到 API 限制且需要重试，或需要启动更多计费系统实例时，这一点就会变得很明显。然后，你就会面临双重收费的风险。幸运的是，贷记/退款并不是一个大问题，但当你扩展基础设施时，这仍然是一个问题。
2. 日期处理。何时计费？每 30 天（日历）还是每个月？闰日、时区等情况如何处理？
3. 按比例分配和“剩余”。在升级时按比例计算还是只降级？退款？积分？忽略？阻止其发生（不允许升级/降级）？
4. 使用量计量。有几十种方法可以决定如何计算用量，而且可以经常更改或按客户类型更改。
5. 发票格式。如果只在一个国家运营，这听起来很简单。但当扩展业务时，你会突然意识到，你不仅要收取销售税，有时还要收取增值税，有时还要收取消费税，有时还要收取附加税（取决于开展业务的国家/地区），因此你现在需要为不同的市场制作单独的模板。
6. 复杂的客户层次结构。客户（尤其是 B2B 客户）可能希望通过子公司和合作伙伴管理自己的计费关系。如何将使用情况汇总到支付实体？
这往往是你一开始没有考虑到的问题，但随着你的业务发展壮大时，情况就会发生变化。
让事情变得更加复杂的是：他们可能在不同的地点，并且根据他们的位置或提供服务的地点征收不同的税。那么，你就必须依法分拆账单/发票。这些规则每隔几个月就会发生变化。
7. 收款和防止流失。何时放弃重试？如何处理退款（终止账户、暂停、退款）？
8. 暂停/恢复。当客户暂停订购时，你允许他们拥有什么级别的访问权限？
9. 入账/退款。如果你总是全额退款，这可能不难，但部分退款怎么办？你是否想用“商店积分”来代替退款？积分是否会过期？
10. 税务处理。你可能认为不同的商品有不同的税率已经够复杂了，但如果你在全球范围内，这些税率也会经常变化。
11. 自定义交易。如果你只使用 PLG，这不是问题，但如果你签订了合同，你很快就会遇到边缘情况和特殊交易，而你所做的假设无法轻松配置这些情况。
12. 人为错误。客户往往是由犯过错误的人组成的，需要进行纠正。企业也是由人组成的，他们可能会错误配置客户，然后需要进行更正。记账和重新开具发票是一项非常耗时的任务。
- 当客户的法律详细信息发生变化（地址、增值税 ID 等）时也是如此。
13. 选择性定价变更。定价变更通常不会影响所有客户。当只有新客户受到影响时，你必须保留不同版本的定价点，以确保遵守客户的协议。
14. 收入确认和应计收入。我甚至无法解释这一点，但这里有一份 64 页的 PDF 文件，是根据《国际财务报告准则第 15 号》制定的收入确认规则（https://www.ifrs.org/content/dam/ifrs/publications/pdf-standards/english/2021/issued/part-a/ifrs-15-revenue-from-contracts-with-customers.pdf）。如果你还做了定制的 ERP 集成，还可以获得额外加分。
为什么这些很难？
有些事情变化非常有规律，超出你的预期。有些事情你只需要做一次，就再也不会碰了。
惰性就是一个很好的例子，工程问题一旦解决，就很少再碰。
然而，世界各地的税收规则经常发生变化。你所处的国家越多，你需要掌握的税法就越多。
围绕错误的客户问题是一个相对持续的问题，但随着企业的发展，这个问题的规模会越来越大，需要更多的客户支持和更多的人工纠正。
让我尝试用表格来说明。这完全是主观臆断，但应该有助于解释事物变化（==中断）的频率与规模影响之间的关系。
计费最初是一个工程问题，根植于一个非常非常复杂的问题空间，即使是业内资深人士也很难理解。
对此，你该怎么办？
尽可能多地把问题推给别人。买现成的东西。能买多少买多少。
这一点我怎么强调都不为过。
在开始使用时，让 Chargebee、Solvimon、Stripe、Recurly、Orb、Metronome、Lago、Togai 或其他任何人管理你的账单。上图中 90% 的“订阅和计费”内容都可以由这些公司处理。
让 Stigg 处理你的定价页面、实验和权利。
让你的企业资源规划系统（ERP）处理你的“收益记录”（RevRec）/会计核算（或使用其他系统内置的功能）。
你只需专注于更新使用情况/基本客户生命周期事件，这些都是你的产品所独有的。
▶英伟达禁止模拟运行 CUDA，中国开发者需要重点关注什么？
▶微软第二次“痛下杀手” ，官宣：Windows 11 上跑 Android 应用以失败告终！
▶雷军：一定把小米汽车干好、干成；QQ测试AI聊天搭子，再战AI社交；零一万物宣布开源Yi-9B模型 | 极客头条