"二清"指平台先归集用户资金、再自行清算给入驻商户，属于无支付业务许可经营支付业务的高风险形态。合规做法是资金留在持牌支付机构或银行体系内，平台系统只输出分账指令与记账台账：订单资金由通道直接分给各应收方，平台仅收取自己那部分服务费，全程账钱分离。
为什么很多平台做到后期才发现资金流有问题
典型路径是：早期用自有收款账户收全款，人工转账给商户，理由是"先跑通业务"。规模一大，账上就沉淀了大量不属于平台的资金，退款、争议与商户挤兑时点集中出现，问题从"算账麻烦"升级为合规风险。业务设计阶段就把资金流画清楚，成本远低于事后迁移。
合规分账架构的四个必备件
- 持牌通道使用微信支付服务商、支付宝或银行存管等的分账产品，商户以特约商户身份进件，资金由通道管理，平台不建立自有资金池。
- 分账规则引擎按比例、固定额或层级配置分润，支持按品类与商户差异化；规则调整只对生效后的订单起作用，历史台账不变。
- 账务台账订单、分账明细、平台服务费、退款冲正逐笔成账，状态机严格约束，不允许通过改数据库来"平账"。
- 对账与差异处理按日或 T+1 拉取通道账单与本地台账逐笔比对，无法自动配对的进差异清单，标注长款、短款与状态不一致，由运营按预设流程处理并留痕。
退款、优惠券与运费：账务最容易错在三个地方
| 场景 | 容易出错的做法 | 正确处理方式 |
|---|---|---|
| 部分退款 | 只退用户，不减商户应收 | 按比例反向冲正各方台账，重算平台服务费 |
| 优惠券补贴 | 按成交价分账，忽略补贴来源 | 明确补贴承担方，分账基数按约定口径还原 |
| 运费与安装费 | 混入商品款一起分 | 单独科目，指定归属方与结算时点 |
| 跨日结算 | 按下单日入账 | 以支付成功/核销日为准，避免长短期资金错期 |
与已有商城对接的改造量有多大
标准做法是在支付回调与退款两个节点接入分账接口：订单侧记录商户与分账规则快照，售后侧发起反向指令。改造集中在支付与售后模块，通常在数个工作日量级，不需要重做商城。真正耗时的往往是历史数据迁移与在途订单的处理策略，需要在切换方案里提前写清楚。
判断一个"分账系统"是否可信，就问一句：钱走不走它的账户。走它账户的，是风险不是功能。
相关问题
必须自己申请支付牌照吗？
不需要，也不建议尝试自行归集资金。正确路径是使用持牌通道的分账产品，让系统只负责台账与指令。
分账比例能随时改吗？
可以按主体或品类配置，但生效范围应只覆盖新订单，历史台账不回溯，否则对账将无法闭环。
数字资产收款能用吗？
工程上可以实现，但境内涉虚拟货币相关业务有明确政策风险，除非主体与场景本身合法合规且有清晰判断，否则不建议采用。