多商家电商平台架构：商家入驻、商品目录、支付、AI与规模化

本技术文章面向正在规划多商家电商平台或将现有店铺转型为电商平台的CTO、架构师和产品负责人。文章介绍平台架构、主要权衡取舍及测试方法，属于信息性内容：如已准备好评估具体建设方案，请访问电商平台解决方案。关于何时有必要采用定制平台的更广泛问题，请阅读定制电商平台指南。另请参阅智能体商务就绪度和多租户SaaS架构，以及电商平台选型。

背景：店铺转型为电商平台后的变化

单商家店铺只有一个目录所有者、一个商家和一套履约体系。电商平台则各有多个，平台居于其间。

每一项都增加了数据、规则和故障模式。架构设计应将每项都明确体现，而非将单商家店铺不断改造直至崩溃。

参考架构

订单在此架构中的流转路径：

1. 购买者结账，购物车中包含来自三个商家的商品。
2. 支付服务商对购买者发起一次扣款。
3. 账本记录每个商家的分成、平台佣金及相关费用。
4. 订单路由创建三笔商家订单，并分别通知各商家。
5. 各商家发货并更新各自订单状态，购买者看到的是一个汇总状态。
6. 保留期结束后，系统将各商家余额划至其银行账户。
7. 某笔商家订单的退款或争议仅调整该商家的余额。

商家入驻与账户管理

入驻速度决定了商品目录的增长速度，因此应将其视为产品流程而非行政表单。优秀的入驻流程仅收集启动所需的信息，允许商家在验证进行中即可发布商品，并在验证完成前仅冻结打款而非商品发布权限。

以下两部分不应从零自建：

• 身份与打款验证。电商平台支付服务可处理此事项。例如，Stripe Connect提供关联账户的入驻选项，收集每个账户所需的验证信息，并管理向其打款。
• 卖家申报义务。在欧盟，DAC7（理事会指令（EU）2021/514）自2023年1月1日起生效，要求数字平台运营商收集并核验卖家信息，并每年向税务机关申报。应在商家数据模型设计时就纳入这些字段，而非事后补录。

商家账户需要各自的角色：所有者、管理商品的员工，以及查看订单和打款的员工。每个商家的查询都必须限定在该商家自己的数据范围内。

商品目录：商家自建商品页还是共享商品目录

大多数时尚和生活方式电商平台倾向于商家自建或精选商品页；标准化商品的电商平台则倾向于共享目录加商家报价。无论选择哪种模式，均应将商品发布纳入流水线：导入、校验必填属性和图片、审核，再发布至搜索索引。消息队列可防止大批量导入影响购买者体验。

支付与打款

资金层是电商平台风险最集中的环节，三个决策决定其走向。

应使用专为平台设计的支付服务，而非将资金汇入自有账户后再手动向商家付款。Stripe Connect是其中一个例子：它允许电商平台向买家收款，并将部分款项划付给卖家，关联账户余额和打款均由服务商管理。无论如何都应维护自有账本，因为佣金、费用、退款和调整必须与服务商记录进行对账；详见结算指南。

银行卡数据应避免进入自有系统。PCI DSS（支付卡行业数据安全标准）为所有存储、处理或传输持卡人数据的主体规定了基本技术和运营要求。使用服务商的托管支付字段或结账页面，可将大部分卡片处理留在服务商侧，从而缩减自身的合规范围。

订单、履约与退货

• 尽早拆单。在结账时即创建商家订单，而非事后处理，以便各商家立即看到各自的工作内容。
• 按商家分别配送。每个商家可能从不同地点发货，运费和时效各异；向购买者展示由此汇总的一个配送概览。
• 汇总状态。购买者看到一笔包含各商家明细的订单；客服人员可查看完整追踪记录。
• 按商家明细处理退货与退款。某商家商品的退货不得影响其他商家的余额。

平台规模化扩展

选择平台基础

Netbase已在WooCommerce、Magento 2、Laravel和headless commerce上交付电商平台，其技术栈还涵盖PrestaShop、OpenCart、Shopware、CS-Cart、Shopify、Salesforce、Akeneo、Odoo和Symfony。对于电商平台项目，选择通常归结为以下三种方案：

无论选择哪种基础方案，均应以API优先的方式设计，使商家应用、合作伙伴数据接入和AI服务与店面使用相同的接口。

安全与信任

电商平台大幅增加了有访问权限的人员数量。应按商家和平台角色实施基于角色的访问控制，为管理员和商家后台启用MFA，数据传输使用TLS加密，静态数据加密存储，并定期进行漏洞扫描。Netbase的交付遵循上述实践，同时包括安全代码审查、渗透测试和灾难恢复规划。还应增加电商平台专项管控：对新商家和异常打款变更进行欺诈检查，对商品和评价进行审核，并对每次银行账户变更保留审计记录。AI风险评分可排序审核队列，但暂停和打款冻结的决定仍由人工做出。

测试证据：上线前的测试项目

以下为通用工程实践，而非特定项目的结果：

• 账本对账测试。针对跨多个商家的生成购物车，包含佣金和费用，确认分成、退款和打款与服务商记录的差额归零。
• 拆单测试。包含一个、多个和大量商家的购物车，含单行的部分退款和取消。
• 访问控制测试。自动化测试一个商家读取或修改另一商家商品、订单或打款的尝试，均须失败。
• 导入压力测试。在模拟购买者流量下运行预期最大商家数据量，检查页面响应时间是否保持正常。
• 打款失败测试。银行账户被拒、打款冻结和争议必须使余额保持正确且可见。
• 排名与风控检查。AI搜索和欺诈评分在影响购买者所见内容或商家冻结决策之前，须与标注的查询样本和历史案例进行比对验证。

案例：欧盟时尚科技电商平台

Netbase为一家从直销转型为电商平台模式的欧盟时尚科技聚合商构建了多商家电商平台，客户名称保密。已发布的案例报告显示，上线6个月内GMV增长47%，商家入驻时间缩短60%。这印证了本文的两个观点：入驻是增长杠杆，以及接入电商平台支付服务商（本案例为Stripe Connect）可将工程资源集中于入驻和目录流程。阅读电商平台案例。

另有两个案例展示了同类组件在其他市场的应用。面向西非及海外侨民社区的RB Marketplace，将商家审批、佣金和打款与基于电商平台API的客户应用相结合。一个在线分类信息平台（创始人未透露姓名）增加了AI过滤功能，可将违规广告标记供管理员审核。这两个案例均未发布业绩数据。

本文的局限性

• 本文描述的是参考架构和通用实践；每个电商平台均需根据其商家、商品和地区进行调整。
• 支付、税务和消费者法规因国而异。DAC7和PCI DSS仅作为需在设计中考虑的合规义务示例，并非完整清单；请咨询法律和税务专业人士。
• Stripe Connect仅作为平台支付服务的一个示例，并非对其优于其他服务商的推荐。
• 欧盟电商平台数据为该客户上线后6个月的自报结果；绝对值未予公开。

下一步

请分享您的商家模型、商品目录规模和支付地区，我们将预约解决方案评审，为您勾画架构和首期发布方案。您也可以查看相关服务，了解Netbase在零售与电商领域的经验，或浏览更多Netbase洞见。

相关服务与解决方案