DAF Trucks 为联网车队功能销售订阅：可以为一辆卡车或整个车队启用服务，并准确计费。GrandVision 在 40 个国家的 7,200 多家门店销售眼镜和镜片的周期性方案。我们为两个项目都建设了平台，但它们的计费都不运行在电商平台内部，而是由 Zuora 负责，电商和自助服务层在前面承接体验。另一方面，一个每四周寄出一袋咖啡的品牌，确实不需要这套复杂能力。
这两种情况的区别，才是订阅项目真正要做的判断。问题在于，所有人都使用同一个词：订阅。
一个词，两个问题
周期性履约是电商问题：同一个购物车按照计划重复执行。每四周发货、扣款、允许跳过或暂停，核心对象是一个订单。
持续性变现是财务问题：合同会随时间变化。周期中途升级需要按比例计费，用量会产生额外费用，车队需要合并发票，失败付款要进入催收流程，还要处理税务和收入确认。核心对象是一个订阅状态机，订单只是它的输出之一。
很多“我们需要订阅”的项目，真正失败的原因，是为其中一种问题选择了工具，却默默需要另一种能力。
commercetools 原生能力覆盖什么
commercetools 的 Recurring Orders 解决第一类问题：购物车附带重复规则，平台每个周期生成一张普通订单。它的优势就在“普通”二字：每张订单仍然经过同一套价格、促销、库存和集成流程。固定周期、实物商品、价格变化只是价格变化时，这套模型配合 PSP 的 token 通常就够了。
阅读文档时要注意一个命名陷阱：commercetools 历史上叫作 Subscriptions 的功能，实际上是把平台消息发送到队列的事件机制，与客户购买订阅无关。真正面向客户的能力是 Recurring Orders。不要让一个名词决定整个项目范围。
原生模型什么时候不够
DAF 的业务需求可以清楚地划出边界：
- 车队经理在月中为 40 辆卡车启用功能，费用需要按比例计算。
- 功能持续增加和删除，财务需要按客户实体合并发票，而不是 40 张订单确认。
- 失败付款需要重试和催收策略，不能简单地把订单标记为取消。
- 合同持续多年，合同变更和收入确认都必须可审计。
- 价格包含承诺量和用量组件，而不是一个固定周期价格。
这些不是订单生成问题，而是合同生命周期和财务核算问题。如果在购物车之上重新实现计费引擎，就必须自己处理按比例计费、日期边界、部分退款、税务周期和收入确认。那正是专业计费平台存在的原因。
前端电商，后端计费
DAF Trucks 和 GrandVision 的生产架构采用清晰分工：
- 前端负责展示和购买。 店铺或门户展示方案，commercetools 或定制层承接浏览和购买；商品与计费方案的映射保持单向、可审计。
- Zuora 负责合同。 结账创建订阅，之后的变更、按比例计费、开票、重试和收入确认都由计费引擎负责。
- 自助服务独立成面。 DAF 的门户可以按单车或车队切换功能；GrandVision 的门户支持查看发票、付款、修改方案，并让多个国家的门店员工减少对工程团队的依赖。
- 事件保持边界一致。 计费状态通过事件向外同步，权益、会计系统和审计轨迹保持一致，而不是靠大量点对点调用。
这个模式不只适用于 Zuora。关键是边界：电商负责客户买什么、如何购买；计费系统负责客户欠什么、为什么欠。
如何做决定
只有在以下条件全部满足时，才适合使用 Recurring Orders 加 PSP：
- 实物商品固定周期补货
- 费用等于订单金额，不涉及按比例计费、用量或承诺
- 取消和跳过是唯一重要的生命周期事件
- 财务接受订单级记录
出现以下任一情况，就应该评估专业计费引擎：
- 周期中途变更需要按比例计费
- 客户需要合并发票或按实体开票
- 催收和失败付款恢复直接影响收入
- 收入确认或审计要求超出订单历史
- 订阅控制的是功能、权限或服务等级，而不是发货
一个很实用的判断方法是写下订阅业务最难的三个客服问题。如果问题集中在包裹，电商原生能力可能足够；如果问题集中在发票和合同，你很可能站在错误的系统边界上。
两个常见错误
商品目录双主。 商品同时存在于电商和计费系统，两边分别修改，最终价格在生产环境发生漂移。确定商业条款的唯一主数据源，让另一侧自动生成，并对漂移报警。
把计费边界情况留到上线后。 月中升级失败、31 号改方案、合并发票部分退款，这些不是罕见情况，而是周二就会发生的事情。它们应该在上线前进入测试计划，因为资金流的正确性最难事后补救。
这套“前端电商、后端计费、事件连接”的方式属于我们的订阅经济服务实践。如果你正在比较周期性订单和专业计费引擎，欢迎带着产品和财务要求来讨论。
