我从开发计费系统中学到的 5 件事

半年前，我加入了 Pleo，一家拥有大约 1.5 万名客户的 FinTech 初创公司。我的主要工作是负责进一步开发计费系统。

刚加入时，我有点担心计费系统能有多少事情要做？我们会不会在三四个个月后就无事可做呢？

新客户注册，支付每月的订阅费，就这样了……对吧？

是的，但实际上也不是。这只是最基本的场景。除了这个，还有大量的边界情况和陷阱需要考虑。

一个个找出这些边界情况并不是件好差事，我希望有人能提供一份简短的指南。于是，我写了这篇文章。如果你正在考虑构建(甚至只是使用)计费系统，可以看一下。

不是所有货币都有小数位

在设计数据库表结构时，有一个普遍观点是“永远不要用浮点数来表示钱”。一些人建议使用MONEY数据类型，另一些人则告诉你要使用DECIMAL。

对于计费系统来说，这两种类型在某些情况下都是错的。当然，在美国和大多数欧洲国家，货币是有小数位的。

在日本，情况就不是这样的——你不能收取 2500.50 日元的费用。除了日本，冰岛的货币也没有小数位。相反，伊拉克第纳尔（伊拉克货币单位）有三个小数位。

从技术上讲，你可以认为整数也是一种小数，但如果你没有考虑到一些情况，有可能会给你的系统带来麻烦。在构建计费系统时，你必须考虑足够的扩展性，以便处理这些国家的货币，即使它们可能不是你当前关注的焦点。

在保存数值时，可以包含可能会使用到的小数位。

例如，在大多数情况下：

• 100 美元可以存为 10000

• 2500 日元存为 2500

• 2500 冰岛克朗存为 2500

• 100 伊拉克第纳尔存为 100000

以下是部分没有小数位的货币。

ISO 4217 标准规定了世界各国的货币编码，可以在维基百科上找到其他更多内容。

票据一旦创建就无法取消

至少在欧洲大部分地区不能取消。在美国，取消未支付的票据是很常见的事情。然而，这在许多欧盟国家是不合法的。如果你因此犯了错，它将成为一个巨大的痛点！

这属于“标准会计”的一部分，但有时它确实很伤人，因为错误总是会不可避免地发生。票据一旦创建，如果你想要取消，只能再创建一个全额的贷记单。

什么是贷记单？你可以把它看成是一种反向票据。贷记单是一种独特的单据，就像发票一样，它们也有自己的编号。

因此，贷记单是一种可以用来将原始发票标记为“已支付”的文件，即使没有发生金钱转移。

不是所有的计费系统都是合规的

当你进入一个新区域开发业务，你要做的不仅仅是为你的产品和服务定价，还必须确保自己遵守各种规章制度——这可能比你想象的要微妙得多。

很多公司从第三方 SaaS 公司购买服务，我们通常认为这样做是合规的。

但我发现情况并非总是如此(当然，我们有责任去核实)。

这里有两个例子：

1.在欧盟，供应商必须在每次销售前确保客户的增值税号码(如果使用了)是正确的。

例如，Stripe 会做一次增值税信息检查，但不做任何其他后续检查，也不检查与客户详细信息是否匹配。

其他一些服务根本什么都不检查，所以请确保你是合规的！

2.欧盟增值税发票必须包含公司增值税的具体信息。然而，很多发票生成器(包括 Stripe 公司)生成的票据甚至不包含增值税信息。

你可能需要找到一种方法，比如利用地址栏备注税务相关信息。无论使用哪种方式，你都要确保自己是合规的！

当用户变更了付费计划该怎么办

我原以为让一家公司成为付费用户是很容易的。他们注册后，经过短暂的试用，就成为付费用户(“Evergreen”)，一切都很棒!

理想情况下，一家公司开始使用产品，在后续的整个生命周期当中都不做付费计划变更（直到退出）。

与很多其他公司一样，我们也提供了不同级别的服务，需要客户预付一个月的使用费。因此，如果客户对服务进行了升级或降级，我们要在未来的某个时刻修改他们的付费计划。

付费计划可以在将来某个时刻发生变化，但客户可能希望立即使用升级后的服务。

这好像没什么问题，直到你开始考虑一些情况：

如果他们想立即使用升级后的服务该怎么办？

我们可以升级他们的付费计划，但不向他们收费。这意味着你需要将计费引擎与指定服务级别的授权引擎分开！

你也可以立即收费，但比例该怎么算呢？

如果他们也想立即为新付费计划付费该怎么办？

这比你想象的要常见得多。我们可以立即进行升级！但是，我们是只收取差价呢，还是把整个月的费用都记在账上，再收取新服务的费用呢？

我们偶然发现了可怕的比例问题，这会导致你、客服和客户很难理解票据上的内容。

一个例子，有时候上面会有几十个细项。

实际上，我们也想把他们的试用期延长一点，这样他们在变更付费计划时就有更长的宽限期。

这个其实没那么难……

但有时候他们在开始付费计划后才想要变更计划。

这真是一个噩梦，你可能还需要赊销一些发票！

可能还会有其他情况发生，虽然可能不是每次都会发生。但随着客户数量的增加，它们就会发生。所以，请提前计划好你要如何处理这些情况！

强行制定规则来应对边界情况？

客户不是公司，他们是人，而且不同的人有不同的需求。

除非你是在非常严格的环境中，否则你必须要考虑强制执行规则的难度。

下面是一些例子：

1.我们只针对英国客户推出折扣。

这样当然可以，但如果一个英国客户在德国有分公司呢？分公司也可以享受这个折扣吗？(答案是肯定的！)

2.我们发起一项活动，每个注册用户都可以免费使用产品，直到 2021 年 4 月 1 日。这适用于所有客户，即使是签订了多年合同的客户。

然而，在签了合同后，一些客户却执意要付费。

3.一些客户想在 2020 年底提前支付 2021 年的费用，因为他们有多余的预算不能在 2021 年使用。

我们的系统不支持提前付费。

除了计划如何应对这些问题，也要考虑是否可以绕过它们，因为这些问题都将可能发生。

在我看来，最好的策略是为业务提供支持，赢得客户，而不是制定太过严苛的规则。

事情从来没那么简单

无论一个问题最初看起来多么简单，它总是有一定的深度和大量需要解答的疑问。

设计和开发计费系统是一件很难的事情，哪怕你只是稍微偏离了“标准”一点点。但如果你努力找到正确的方法，带给你的将是快乐的客户、快乐的销售和支持代表，以及快乐的财务部门！

这些是我在开始开发计费系统前希望知道的 5 件事，当然，它们并不能代表全部。

原文链接：

https://arnon.dk/5-things-i-learned-developing-billing-system/#comments?fileGuid=DxvCG6DLD0MWCpuw