先画清楚角色和订单边界
多商户平台的分账流程应从业务关系开始，而不是从接口字段开始。先明确消费者、平台、入驻商户、渠道或服务方分别做什么，以及一笔订单是否包含多个商户、商品或履约单元。
订单边界会直接影响退款、规则匹配和结算。如果一个平台订单包含多个商户，应保留可以独立定位的商户订单或明细，避免后续只能按总额处理。
建议先确认的对象
平台订单、商户订单和商品明细之间的关系。
商户主体、门店、品牌或服务者的唯一标识。
平台服务费、商户货款、渠道费等费用项目。
支付、履约、取消和退款等状态的定义。
六步设计多商户分账流程
建立订单主线：统一订单号、商户归属、明细与支付结果。
建立参与关系：把平台、商户和服务方关联到具体订单。
定义规则边界：明确计算方式、优先级、生效范围和版本。
确定触发状态：决定在支付、发货、履约或其他节点计算。
设计退款调整：明确部分退款会影响哪些角色和费用。
衔接对账结算：让汇总结果可以下钻到分账与原订单。
规则设计表
规则维度 | 示例问题 |
|---|---|
适用对象 | 全平台、某商户、某品类还是某活动 |
计算方式 | 固定金额、比例还是条件组合 |
生效边界 | 从哪个时间或订单开始使用 |
异常处理 | 金额不足、角色缺失时如何处理 |
业务示例：一笔跨店订单
用户在同一平台订单中购买了甲、乙两家商户的商品，并使用平台优惠。系统首先拆分可独立追踪的商户订单，分别确认商品金额、优惠承担和服务费用，再为两家商户生成各自的分账明细。
如果只退甲商户的一件商品，调整应限定在对应商户订单和相关费用项目内，不应改变乙商户的已确认明细。平台优惠如何分摊、服务费是否调整，应在规则中提前约定，而不是退款发生后临时判断。
退款与异常流程怎么设计
用原订单驱动调整
退款请求必须携带稳定的原订单或明细标识。系统读取原分账结果和当前状态，确定影响范围并生成新的调整记录。
对重复请求保持幂等
网络重试不应重复生成退款或分账结果。请求标识、业务动作和已有结果之间需要明确对应关系。
把无法自动判断的情况集中处理
角色缺失、跨周期调整或状态冲突应进入待处理队列，记录原因、负责人和最终处理方式。
上线前如何验收
覆盖单商户、多商户、满减优惠和不同服务费规则。
覆盖全额退款、部分退款、跨店退款和重复通知。
检查规则版本变更前后的订单是否使用正确口径。
从结算汇总反向追踪到商户、分账记录和订单明细。
验证接口超时、通知失败和数据缺失时的恢复方式。
常见问题
多商户订单一定要拆成多个订单吗
不一定要改变用户看到的订单形式，但系统内部需要有可独立定位商户和明细的结构，才能准确处理分账、退款与结算。
平台优惠如何参与分账
应先明确优惠由谁承担、如何分摊、退款时如何返还，再把口径配置为规则。不存在适用于所有平台的统一答案。
商户费率可以随时修改吗
可以变更未来适用规则，但需要记录版本和生效边界。历史订单应保留实际使用的规则，避免重新计算后无法解释原结果。