多商户平台小程序方案前期需要准备哪些资料？

多商户平台项目刚开始沟通时，常见的一句话是：“做一个类似商城的小程序，让商家自己入驻和卖货，平台抽点佣金。”听上去已经把业务说清了，真正往下问，往往每个词都还有另一层意思。

商家是提交申请后由平台审核，还是由总部统一创建？消费者买了三家店的商品，是付一次钱还是分三次付？货款直接进商家的账户，还是先到平台再结算？谁给消费者开发票，退货运费又由谁承担？这些问题只要有一个没有答案，功能、支付方案、合同责任和项目报价都会跟着摇摆。

红数科技在方案前期通常会先拿一笔跨店订单来核对：消费者向谁买，钱付给谁，订单怎样拆，哪家商户发货，平台收取什么费用，发生退款时原来的佣金怎样退。能把这笔订单从下单讲到结算，后面的资料才有真正的落点。

先确认做的是哪一种“多商户”

多商户只是表面形态，实际可能是完全不同的生意。

一种是平台型商城。不同经营者入驻，分别经营店铺、发布商品和履约，平台提供交易场所、规则与技术服务。另一种是品牌连锁或多门店商城，门店看起来各自经营，商品、价格、收款和售后仍由总部统一管理。还有一种是给多个客户开独立店铺的 SaaS 系统，每个商户有自己的店和交易入口，商户之间不一定共享购物车、会员和订单。

这三类项目都能在页面上做出“店铺列表”，但账户、支付、数据隔离和平台责任并不一样。前期最好先准备一页业务说明，写明：

• 平台运营主体、入驻商户和消费者分别是谁；
• 商户是独立经营者、直营网点、加盟店，还是系统使用方；
• 商品所有权属于谁，页面上显示的销售方是谁；
• 商户能不能自己定价、上架、发货、退款和开票；
• 平台收入来自佣金、技术服务费、广告费、会员费，还是自营商品差价；
• 用户能否跨店购物，会员、优惠券和积分是否跨店通用；
• 平台是否同时经营自营店，自营商品与入驻商户商品怎样区分。

名称可以晚一点定，交易关系不能晚。把一个平台招商项目误按连锁门店系统设计，后面改动的不会只是店铺字段，支付、订单、售后、财务和后台权限都要重做。

平台主体、账号和许可资料要先核对

平台公司需要准备的不只是营业执照，还要把小程序主办单位、实际运营主体、支付主体、开票主体和合同签约主体放在一起核对。名称不一致并不等于一定不能做，但必须有真实业务关系和相应授权，不能到申请支付或提交审核时才解释。

建议提前整理这些资料：

微信开放文档当前列出的小程序备案材料包括主办单位证件、主体负责人证件、小程序负责人证件，以及业务需要的前置审批或补充材料；备案过程中还涉及负责人核验和工信部短信核验。新闻、出版、药品和医疗器械、网约车等业务可能需要相应前置审批文件。具体材料要按真实主体和服务类目准备，旧项目资料不能直接照搬。

商户入驻资料不能只做成一张申请表

平台对入驻商户要有一套从申请、核验、签约到退出的处理方式。前期应先准备几家有代表性的商户资料，实际走一遍审核，才能判断字段是否够用。

商户主体资料通常包括营业执照或登记证书、经营者或法定代表人信息、经营地址、联系人、结算账户、开票资料、品牌与经销授权。食品、出版物、医疗器械等具体经营内容，还要按类目收取对应许可。店铺资料则包括店铺名称、Logo、介绍、客服时间、发货地、退货地址、经营类目和售后承诺。

同时要写清平台怎样处理这些资料：谁审核，哪些字段需要人工复核，证照到期前是否提醒，经营类目变更后是否重新审核，商户被投诉、停业或退出时，未完成订单、退款、余额和历史记录怎样处理。只完成“提交成功”页面，后面没有驳回、补正、冻结和退出规则，商户管理就只做了一半。

《电子商务法》要求电子商务平台经营者核验、登记平台内经营者提交的身份、地址、联系方式和行政许可等信息，并建立平台服务协议与交易规则；《网络交易监督管理办法》对平台内经营者信息核验、更新和报送也有进一步规定。需要保存哪些原件、由谁复核、保存多久，应由平台结合实际业务和现行规定确认。

支付和结算资料要先回答“钱怎样走”

多商户项目里，页面上的“平台抽佣”只是一条计算规则，资金能否按设想收取和分配，还取决于交易关系、支付产品能力、商户进件和账户配置。

截至 2026 年 7 月，微信支付“平台收付通”将平台型电商的支付与结算单独作为一套解决方案。官方文档说明，平台商户协助下属商户入驻成为微信支付二级商户；合单支付可以把多个二级商户的订单合并支付，款项分别进入相应二级商户账户；平台还可在满足业务条件后发起分账、解冻资金并收取佣金。当前接入文档也明确列出了不同商户类型的进件资料、签约、审核和账户验证流程。

这不代表所有多商户项目都必须采用同一种支付方案。前期真正要准备的是已经确认过的资金说明和计算样例：

• 消费者看到的收款方是谁，商户是否需要完成支付进件；
• 平台佣金按商品金额、实付金额还是扣除运费后的金额计算；
• 支付手续费由平台还是商户承担，优惠补贴由谁出；
• 结算以支付、发货、确认收货还是售后期结束为条件；
• 一笔跨店订单退款时，商品款、运费、优惠、佣金和分账怎样回退；
• 商户什么时候能看到账单、可结算金额和实际到账金额；
• 平台、商户和消费者之间分别由谁开具什么发票。

建议让财务提供三到五个脱敏算例，至少覆盖正常交易、平台优惠、部分退款、结算后退款和跨店合单。产品、财务和开发按同一组数字计算，结果一致以后，结算规则才算真的定下来。

商品、店铺和内容资料要分清归属

多商户平台的商品资料比单店商城多了一层归属关系。同一品牌、同一条码的商品，可能由多家店销售，价格、库存、发货地和售后条件又不相同。平台要先决定是“一店一商品”，还是建立平台标准商品库，再让商户创建自己的在售记录。

无论选哪种方式，都要准备真实样本，覆盖单规格、多规格、多店同品、不同运费、预售、缺货和受限类目。商品字段至少要能区分平台商品编码、商户商品编码、SKU、所属店铺、品牌、类目、价格、库存、发货地、运费模板和售后规则。

商品图片、详情、参数和资质由谁提交，平台审核什么，也要定清。平台可以统一页面规范，但不能默认拥有商户图片和品牌素材的使用权。影响搜索、筛选、交易和售后的信息，应保存为可维护字段，不要全部塞进一张详情长图。

一笔跨店订单要把拆单、履约和售后全部走完

用户在前台支付一次，后台通常已经变成平台单、商户子单、包裹和支付明细等多条记录。前期资料中要用一笔真实订单说明：购物车能否跨店，优惠先按平台还是店铺计算，运费按店铺、仓库还是整单计算，付款后怎样拆给各商户，平台和商户各自能看到什么。

履约不能只写“商户自行发货”。还要确认发货时限、物流公司、电子面单、一个子单多包裹、缺货、拒收和超时不处理的规则。平台是否可以代商户发货或强制退款，也应在权限和协议里找到依据。

售后尤其要区分平台与商户的责任。申请由商户先处理还是平台客服先受理，平台在什么条件下介入，部分商品退款会不会影响整单优惠，退货地址由哪家店提供，商户拒绝后用户能否申请平台复核。没有这些规则，后台即使有“同意”和“拒绝”按钮，真正发生争议时也不知道该由谁操作。

后台角色和数据边界要按实际岗位准备

平台管理员、招商审核、类目运营、财务、客服、风控和数据人员，看到的数据与可执行的动作不应该完全相同。商户侧也可能有店主、运营、客服、仓库和财务账号。前期应准备角色清单，并把查看、新增、修改、审核、导出和资金相关操作分别确认。

这里容易被忽略的是数据隔离。商户只能查看自己的顾客和订单，还是可以沉淀平台会员？平台运营能否查看完整手机号、收货地址和聊天记录？导出订单是否留痕？员工离职后怎样停用账号？这些都不是后台上线后再加几项权限那么简单，会影响数据表、接口和日志设计。

小程序如果处理手机号、收货地址、定位、相册或发票信息，需要列出收集页面、用途、必要性、保存期限、使用岗位、第三方接收方和用户权利处理方式。微信开放文档要求，涉及处理用户个人信息的小程序补充用户隐私保护指引，提交审核时还会核对版本中的隐私接口调用与指引内容。《个人信息保护法》要求处理目的明确、合理，并采取对个人权益影响最小的方式，收集范围限于实现目的的最小范围。

现有系统和外部接口要确认到负责人和测试条件

项目需要连接 ERP、WMS、OMS、CRM、电子发票、物流、地图、短信、客服或数据分析服务时，不能只提供软件名称。应准备版本、部署方式、已购买模块、接口文档、测试环境、测试账号、调用限制、字段说明和对接负责人。

每类数据都要确定最终来源。商户和商品由平台后台维护还是从其他系统同步，库存冲突时以哪套系统为准，订单状态由谁回传，退款和分账结果怎样对账。旧平台需要迁移时，还要列出商户、商品、会员、未完成订单、余额和历史账单的迁移范围，以及旧编码与新编码的对应方式。

接口暂时拿不到，可以把它列为待验证项，并约定确认时间。没有经过第三方验证就把实时库存、自动开票或结算打通写成确定范围，后面很难守住工期和费用。

开工资料要能直接支持原型、报价和验收

资料是否准备到位，不看文件数量，主要看团队能不能据此做决定：产品能否画出正常流程和异常状态，开发能否确定字段与接口，测试能否判断每个结果是否正确，财务能否对上每一笔金额。

正式开工前，建议把文件按下面的目录整理：

01_平台模式与交易关系
02_平台主体与账号资质
03_商户入驻与审核资料
04_店铺商品与媒体素材
05_订单履约与售后规则
06_支付分账结算与发票
07_平台协议与商户规则
08_角色权限与个人信息清单
09_外部系统接口与数据迁移
10_原型确认与验收用例

资料还没全部齐，可以先做需求梳理和原型，但平台经营模式、销售主体、收款路径、商户审核、订单拆分、退款结算和数据边界不能带着含糊答案进入开发。这几项一旦改变，受影响的通常是一整条交易链。

最实用的开工检查，不是再过一遍功能名称，而是选一家商户、两个 SKU 和一笔跨店订单，从商户申请入驻开始，一直讲到消费者退款、平台退回佣金、财务完成对账。中间每个身份有资料，每个数字有来源，每个异常有处理人，这份多商户平台小程序方案才真正具备开发条件。

参考资料

以下公开资料核验于 2026 年 7 月 24 日。平台服务类目、申请材料、审核流程和支付能力可能调整，实际项目应以申请与接入时的官方页面为准。

[2]: 工业和信息化部，《关于开展移动互联网应用程序备案工作的通知》，工信部信管〔2023〕105 号。 [3]: 中国人大网，《中华人民共和国电子商务法》。 [4]: 中国政府网，《网络交易监督管理办法》。 [5]: 微信支付合作伙伴文档中心，《平台收付通：产品介绍》，页面更新时间：2026 年 2 月 28 日。 [6]: 微信支付合作伙伴文档中心，《平台收付通：开发接入准备》，页面更新时间：2026 年 5 月 19 日。 [7]: 微信开放文档，《用户隐私保护指引填写说明》。 [8]: 中国人大网，《中华人民共和国个人信息保护法》。