聚合支付与服务商模式：多通道接入、子商户进件与分账

聚合支付与服务商模式：多通道统一接入、子商户进件与分账

平台型业务——电商平台、SaaS 工具、连锁门店、内容付费社区——几乎都会遇到同一个问题：用户想用支付宝就用支付宝、想用微信就用微信、企业客户还想走银联，于是要接三套接口、维护三套回调、做三份对账、处理三套退款规则。更麻烦的是钱该进谁的账户。

这件事有三条不同的解决路径，边界必须搞清楚，因为选错不只是技术问题，还可能是合规问题。单通道的接入细节见微信支付 APIv3 接入实操与支付宝开放平台接入实操。

直连模式：商户自己与支付宝、微信支付、银联分别签约，钱分别结算到自己的账户。技术上是三套独立系统，资金关系最清晰。

服务商模式：你作为服务商接入支付宝或微信支付，再为旗下商户批量创建子商户号。用户付款时，钱直接进入子商户账户，服务商只负责技术与运营。这种模式适合平台、SaaS 服务商、连锁品牌总部。

聚合支付：由第三方把多个通道封装成一套接口与一套回调，你只对接它一家。它解决的是接入效率问题，不改变资金归属。

三者的关系不是替代而是叠加：一个平台可能同时是微信支付服务商（为商户创建子商户号），又通过聚合支付服务商统一技术接入。

必须说清楚一个概念：平台代收用户的钱，再自己结算给商户，这叫二次清算（俗称二清），属于无证经营支付业务。监管对聚合支付服务有过专门的清理整治要求，核心就是"聚合支付机构不得从事资金清算业务"。

判断标准非常朴素：钱有没有经过你的账户。

所以平台型业务在设计收款方案时，第一个要回答的问题不是"用哪个聚合支付"，而是**"这笔钱最终应该进谁的账户"**。分账能力的存在，正是为了让钱不进平台账户也能分给多方。

以微信支付与支付宝为例，服务商模式的落地路径大致是：

几个容易出问题的点：进件材料必须真实且与经营场景一致，行业类目选错会导致费率不符或功能受限；结算账户必须是商户自己的对公账户或法人账户，绑定服务商账户就变成二清了；子商户有独立的费率与权限，不能假设与主商户一致。

当一笔订单需要分给多方——平台佣金、供应商货款、分销佣金、服务商分成——需要用分账能力。国内主流做法有两类：

通道侧分账：使用微信支付分账或支付宝分账产品，在支付成功后按规则把资金分给指定接收方。优点是资金不经过平台账户，合规性最好；限制是接收方需要先完成进件或绑定，分账比例与时间窗口有平台规则约束。

持牌机构清分：通过持牌支付机构做资金归集与清分，由机构按指令划付。适合分账方数量多、规则复杂、需要跨通道统一处理的场景，成本与接入复杂度更高。

选择判断：分账方少、规则简单、以微信支付宝为主 → 通道侧分账；分账方多、跨通道、规则复杂 → 持牌机构清分。

即使用了聚合支付，也建议在业务侧做一层统一抽象，否则未来更换或增加通道时改动会扩散到全站。这一层至少要统一四件事：

关键设计是内部订单号与通道流水号分离：内部订单号由你生成且全局唯一，通道流水号只作为属性记录。这样更换通道时订单体系不受影响。

另一个要点是支付路由：当同一笔订单可以通过多个通道完成时，按可用性、费率、成功率做路由选择。路由策略要可配置、可灰度，不要硬编码在代码里。

坑一：回调格式不一致。不同通道的通知报文结构、成功响应格式、重试策略都不同，统一入口必须按通道分别验签与应答，不能用一套逻辑处理。

坑二：金额单位不一致。微信支付以分为单位，支付宝以元为单位，聚合层的差异更隐蔽。归一化时统一转成"分"这类整数最小单位，避免浮点误差。

坑三：回调与查单不一致。部分聚合支付的回调延迟明显，或者丢通知。必须实现定时查单兜底，不能只依赖回调。

无论选哪条路，都要在合同与技术上确认一件事：资金流向是"用户 → 商户"还是"用户 → 平台 → 商户"。后者就是二清。

资金流路径已在方案文档中画清并确认无二清；商户进件材料与经营类目一致；结算账户归属商户本人；分账接收方已完成进件；统一回调层按通道分别验签；金额统一以最小货币单位整数存储；定时查单兜底已上线；对账表已归一化并覆盖全部通道。

分账后的对账方法见对账与账单下载操作手册，退款与结算见退款与清结算操作手册，聚合服务商的产品定位可参考 Ping++，跨境场景的通道组合见跨境支付平台选型矩阵。更多支付方案可参见支付分类。

来源：16IDC 原创，文中涉及的产品能力、费率与准入要求以 pay.weixin.qq.com 等官网文档及合同为准。