B2B2C商城小程序开发

先确认企业要做的是不是B2B2C商城

B2B2C商城小程序也叫多商户商城、平台招商商城或商家入驻小程序。平台经营方搭建统一商城，多个商户开设店铺、发布商品并处理各自订单，消费者在同一个小程序内完成浏览、购买和售后。平台通常负责商户审核、经营规则、公共页面、交易秩序和平台服务，商户负责商品、库存、履约以及约定范围内的售后。

它与单商户商城的区别不在首页多了几个店铺，而在经营主体、订单归属、资金路径和责任分工都变了。

如果所有商品都由平台企业销售、统一发货、统一开票，只是按品牌或供应商分类展示，通常仍属于B2C自营商城。若商户只是内部供应方，并不面对消费者独立经营，也不一定需要完整的商户入驻体系。先把关系判断准确，往往能省去不必要的后台和后续返工。

四个问题决定系统怎样建

多商户商城开发前，平台负责人、业务、财务和法务应共同确认四件事：商品以谁的名义销售，消费者的钱进入谁的账户，发票由谁开具，退换货和消费争议由谁处理。这四个答案会影响支付产品申请、商户协议、页面公示、订单字段、结算报表和客服权限。

不能默认把所有消费者货款收进平台普通账户，再按后台数字转给商户。具体能否采用电商收付通、分账、商户独立收款或其他方案，取决于平台业务、主体资质、微信支付当前产品规则及实际签约结果。项目立项时应由平台企业同财务、法律顾问和支付服务方确认，红数科技据此完成接口和账务记录设计。未获开通的支付能力，不能用界面演示代替真实可用条件。

消费者、商户和平台分别使用什么

一套可运营的B2B2C商城至少有消费者小程序、商户经营端和平台管理端。三端数据彼此关联，但不能让所有人看到同样的信息。

同一个人可能兼任多个岗位，但权限仍应分开。平台招商人员不应直接修改支付配置，商户只能查看自己店铺的数据，客服查看手机号、地址等信息要符合工作需要，导出、退款、结算和封店等高风险操作应保留操作人、时间、前后状态和处理原因。

商户入驻不是填一张申请表

商户能否进入平台经营，取决于平台准入规则、经营类目和所需资质。开发时要把申请、审核、补充材料、通过、驳回、停用和退出做成完整状态，而不是后台手工改一个“已入驻”。

• 商户提交企业或个体工商户资料、联系人、店铺信息及经营类目；
• 不同类目按平台规则上传相应许可、品牌授权或其他证明；
• 平台审核人员查看材料、记录意见，并要求缺失资料重新提交；
• 审核通过后签署或确认相应版本的入驻协议和平台规则；
• 按获准的支付方案完成商户信息或收款关系配置；
• 店铺开通后，商户在自己的权限内维护商品、库存、订单和售后；
• 资质到期、违规经营、协议终止或主动退出时，按规则限制经营并保留必要记录。

证照图片、身份证明、联系人信息、结算资料等包含敏感内容。系统应按实际需要收集，明确用途和保存期限，限制后台查看与下载，并通过HTTPS、访问控制、日志、备份和必要的加密措施保护。不能因为“以后可能用到”而让所有商户一次提交与经营无关的资料。

商品上架前，平台要管到什么程度

多商户平台通常需要“商户维护、平台监督”的商品管理方式。是否逐件审核，可按经营类目和平台制度确定，但系统至少要能识别商品属于哪家店、由谁修改、处于什么状态。

平台若允许特殊食品、医疗健康、教育培训或其他受监管类目经营，还要先确认主体、类目和许可证要求。程序可以保存和提示资质，不能替代平台对商户与商品合法性的审查。

一次购买多家店，订单怎样拆

消费者可以把多家店的商品放入购物车，但后台不能只留一张总订单。常见做法是生成一张平台交易单，再按商户或履约方拆成子订单。优惠、运费、支付、退款和结算都要能追溯到对应子订单和商品明细。

状态设计要覆盖正常和异常情况：待付款、已付款、待发货、部分发货、已发货、已完成、已关闭、售后中、部分退款和全部退款。支付通知可能重复到达，接口可能暂时超时，商户也可能误操作。后端应保证同一通知不会重复扣库存或重复入账，并为失败任务保留重试和人工核查入口。

平台收费和商户结算必须能对账

平台可能按订单比例、固定金额、类目、商户等级或服务项目收取费用。系统能支持什么，必须以合同确认的计算规则为准。开发前至少要说明计算基数、退款后是否退还、优惠由谁承担、结算周期、最低结算金额、争议订单是否冻结以及异常差额如何处理。

结算单不应只有一个“应结金额”。财务至少要能追到商户、订单、商品实付、退款、运费、优惠承担、平台服务费、其他约定费用、已结金额和待结金额。系统报表用于记录和核对，最终账务与税务处理仍以实际支付渠道、银行记录、合法凭证和企业财务制度为准。

平台不得把后台显示“已结算”当作真实资金已经到账。开发验收应使用获准的测试或生产支付环境，核对支付单号、退款单号、渠道状态和结算结果；支付产品尚未开通时，只能验收已完成的程序范围和模拟业务规则，并在交付记录中写明未完成条件。

售后不能只留给商户自己处理

消费者购买后首先面对的是平台小程序。即使商品由入驻商户销售，平台也需要按自己的规则提供可找到的售后入口、处理进度和争议介入方式。

标准售后可按项目包括仅退款、退货退款、换货或补发。平台要确定商户响应时限、退货地址、收货确认、举证材料、退款权限、平台介入条件和申诉记录。涉及多店订单时，消费者应能针对具体商户和具体商品发起申请，不能为了退一件商品取消整张订单。

评价、投诉、违规和商户退出也要留有边界。商户退出前应处理未完成订单、售后、结算和必要的数据留存；店铺关闭后，消费者的历史订单与合法售后记录不应随之消失。

开发前需要准备的资料

• 平台企业主体、业务说明、计划经营类目和商户来源；
• 平台与商户、消费者之间的权利责任及协议文本；
• 销售、收款、开票、履约、售后和争议处理的责任人；
• 微信小程序账号、AppID、管理员、认证、备案和服务类目资料；
• 计划申请的微信支付产品、商户号、结算账户及申请进度；
• 商户入驻字段、审核材料、协议确认和退出规则；
• 商品类目、属性、SKU、库存、运费、发票与上架审核规则；
• 平台活动、店铺活动、费用承担与退款后的计算方式；
• 平台收费、结算周期、冻结条件和财务对账样表；
• 客服、运营、招商、审核、财务和管理员的权限分工；
• ERP、WMS、物流、短信、电子发票、客服等接口资料；
• 现有商户、商品、会员或订单数据的迁移范围和质量。

第三方接口不能只写“需要对接”。例如对接ERP，应明确商品、库存、订单、发货、退款中的哪些数据由哪一方提供，实时还是定时同步，失败怎样补偿，接口限额、费用、测试账号和维护责任由谁承担。

项目从业务确认开始，不从首页设计开始

1. 业务确认：核对平台经营方式、商户角色、商品类目、收款开票、履约售后和现有系统。
2. 规则定稿：确认入驻审核、商品审核、订单拆分、优惠、库存、退款、平台收费、结算和权限。
3. 原型设计：画清消费者购买、商户经营和平台管理的主要页面、状态与异常处理。
4. 视觉设计：按品牌资料完成消费者端和关键后台界面，确认常用操作与移动端显示。
5. 程序开发：开发小程序、商户端、平台后台、服务器程序、数据库和约定接口。
6. 平台联调：连接登录、支付、退款、订阅消息、物流及合同内的第三方能力。
7. 场景测试：使用多店、多规格和不同权限账号完成下单、拆单、发货、退款与结算测试。
8. 备案审核：配置服务器域名、隐私说明、主体、类目和备案资料，提交平台审核与发布。
9. 培训交接：分别培训平台运营、财务和商户管理员，交付账号、资料及约定源码。

在原型和规则确认后增加新的结算方式、营销活动、商户类型或外部系统，通常会同时影响数据库、页面、接口和测试，不属于简单增加一个按钮。变更应重新确认范围、时间和费用。

周期要看交易规则和接口条件

以下时间用于项目前期判断，正式排期以功能清单、设计要求、支付方案、资质和接口准备情况为准。

周期不包括客户长期未提供主体资质、协议、支付产品、商品资料或接口环境的等待时间。微信审核和支付产品申请由平台按现行规则处理，开发方可以协助准备和调整，不能承诺固定通过日期。

服务费用怎样估算

B2B2C商城的报价不能按页面数量简单计算。消费者端看起来相近，商户权限、订单拆分、退款分摊、结算规则和外部接口不同，开发与测试工作可能相差数倍。

以上是定制开发的前期估算，不是固定报价。成熟SaaS系统的初期费用可能更低，但应核对年费、交易相关费用、扩展限制、数据导出、停服迁移和源码归属。独立定制费用较高，适合规则明确、需要长期迭代或必须连接现有系统的平台。

正式报价应写明页面和功能清单、商户端形式、设计范围、支付方案、接口数量、数据迁移、代表商户与商品录入量、服务器配置、第三方费用、修改次数、源码和设计源文件、维护期限及新增需求的计费方式。微信认证、支付、短信、物流、电子发票、地图、服务器及其他第三方费用是否包含，也要逐项注明。

哪些企业更适合建设这类平台

• 已有稳定的行业商户资源，能够持续完成招商、审核和服务；
• 平台对交易类目、商户责任、售后和违规处理已有基本规则；
• 需要统一商城入口，同时让商户管理自己的商品与订单；
• 有运营、客服、财务和技术协作人员，不把商城当成无人管理的工具；
• 现有人工对账和订单转发容易出错，需要形成可查询记录；
• 准备长期运营，并愿意分阶段上线、验证和持续调整。

如果企业还没有商户来源，也没有确定谁收款、谁开票、谁售后，建议先完成经营方案和合规评估，再决定开发范围。程序能执行确定的规则，不能替企业决定平台应怎样经营。

交付内容要按三端写进合同

• 经确认的业务说明、功能清单、字段、状态、权限和接口范围；
• 消费者端、商户端和平台端的主要原型与视觉设计稿；
• 可提交审核的微信小程序前端程序；
• 商户入驻、店铺、商品、订单、售后和结算等约定功能；
• 平台运营、审核、客服、财务、权限和日志等管理后台；
• 服务器程序、数据库、部署配置和合同约定的第三方接口；
• 代表商户、店铺、商品、SKU、订单和结算测试数据；
• 功能、接口、支付退款、权限和安全测试记录；
• 小程序备案、服务类目、隐私说明、审核与发布协助；
• 管理账号、操作手册、培训记录、部署资料及维护边界；
• 合同约定的自研源码、设计源文件或第三方授权说明。

源码交付取决于开发方式。独立定制项目可按合同交付自研部分源码和部署资料；开源系统二次开发仍受原许可证约束；SaaS系统通常交付使用权和业务数据，不会交付平台全部源码。签约前要把这三种情况分开写清。

验收要用至少两家商户跑完整交易

验收不能只走一笔最顺利的订单。至少准备两家商户、跨店购物车、多规格商品、低库存商品、平台优惠和店铺优惠，覆盖未付款关闭、支付成功、分别发货、单店退款、部分退款、商户超时、平台介入和结算冻结。涉及真实支付时，以支付渠道的订单、退款和结算记录共同核对。

上线条件和双方责任

小程序上线通常需要实际经营主体持有账号和AppID，完成微信认证、小程序备案、服务类目、服务器域名、隐私保护说明及相应资质配置。交易功能还要准备符合业务和签约要求的微信支付产品与商户资料。平台规则、接口和支付产品会调整，项目实施时以微信开放文档、小程序备案操作指引、用户隐私保护指引填写说明以及微信支付商户平台当期说明为准。

红数科技负责按合同完成需求、设计、开发、测试、提交、交接和约定期限内的程序故障处理；平台企业负责主体与商户资料真实有效，制定经营、商品、收费、履约、发票、售后和数据使用规则，并妥善保管小程序、支付、服务器和管理员账号。审核结果、支付产品申请和商户经营结果受平台规则、主体资质及实际运营影响，不能由开发方单方面保证。

新增商户模式、改变资金路径、接入新系统、增加复杂活动或重做已确认页面属于功能调整，需要重新评估。第三方接口、平台规则或支付产品变化引起的适配，按维护合同和实际影响处理。

B2B2C商城真正难的不是让多个店铺出现在首页，而是让每一件商品知道由谁经营，每一笔订单知道由谁履约，每一次退款知道退给谁，每一笔费用都能回到原始交易。把这些日常细节做扎实，平台才能在商户增加、订单增多以后继续管得住、查得清。