多供应商平台架构：供应商、目录、支付、AI与规模化

本技术文章面向正在规划多供应商平台或将现有商店转型为平台的CTO、架构师和产品负责人。文章介绍架构方案、主要权衡与测试方法，仅供参考：如已准备好启动项目，请前往电商平台解决方案。关于何时适合构建定制平台，请参阅我们的定制电商平台指南；另请参见智能体商务就绪评估、多租户SaaS架构和平台选型对比。

背景：商店转型为平台后有哪些变化

单一卖家商店只有一个目录所有者、一个商家和一套履约体系。平台则有多个卖家、多个商家和多套履约体系，而平台本身处于它们之间。

每一行都增加了数据、规则和故障模式。架构设计应将这些问题显式处理，而不是强行改造单一卖家商店直至其崩溃。

参考架构

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

1. 买家结账，购物车中包含来自三个供应商的商品。
2. 支付服务商向买家收取一笔款项。
3. 账本记录每个供应商的分成、平台佣金及各项手续费。
4. 订单路由创建三个供应商订单并分别通知各供应商。
5. 各供应商发货并更新自己的订单状态；买家看到统一的汇总状态。
6. 持仓期结束后，系统将各供应商余额打款至其银行账户。
7. 某一供应商订单的退款或纠纷仅调整该供应商的余额。

供应商入驻与账户管理

入驻速度决定目录增长的快慢，因此应将其视为产品流程而非行政表单：只采集启动所需的最少信息，允许供应商在验证进行中即可上架商品，并以暂停打款（而非暂停上架）作为验证未完成时的限制措施。

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

• 身份与打款验证。平台支付服务专门处理这类需求。以Stripe Connect为例，它为关联账户提供入驻选项，采集各账户所需的验证信息，并管理打款流程。
• 卖家报告义务。在欧盟，DAC7（欧盟理事会指令2021/514，自2023年1月1日起适用）要求数字平台运营商采集并核实卖家信息，并每年向税务机关报告。在设计供应商数据模型时，应在入驻阶段即采集这些字段，而非事后补充。

供应商账户需要自有角色体系：所有者、管理商品的员工，以及查看订单和打款的员工，所有查询均限定在该供应商的记录范围内。关于入驻流程本身，请参阅AI卖家入驻指南，了解目录数据采集方式与审核队列设计。

目录：供应商自有商品还是共享产品目录

大多数时尚与生活方式平台倾向于供应商自有或精选商品；标准化商品平台则倾向于共享目录加报价模式。无论选择哪种模式，商品均应经过流水线处理：导入、校验必要属性和图片、审核，再发布到搜索。目录模式确定后，使其对AI购物智能体可读是一个独立的Schema设计、数据Feed与工具接口决策；请参阅我们的智能体就绪目录指南。

支付与打款

资金层是平台风险最集中的环节。以下三个决策至关重要。

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

银行卡数据应与自有系统隔离。PCI DSS（支付卡行业数据安全标准）为任何存储、处理或传输持卡人数据的主体设定了基准技术与运营要求。使用服务商托管的支付表单或结账页面，可将大部分卡片处理保留在服务商一侧，从而缩小自身合规范围。

订单、履约与退货

• 尽早拆单。在结账时即创建供应商订单，而非事后处理，使每个供应商能立即看到自己的任务。
• 按供应商分别配送。各供应商发货地点、运费和时效可能不同；向买家展示由此汇总的一份配送摘要。
• 汇总状态。买家看到包含各供应商明细的统一订单；客服人员可查看完整的操作记录。
• 按供应商明细处理退货和退款。某一供应商商品的退货不得影响其他供应商的余额。

平台规模化

选择平台基础架构

Netbase已在WooCommerce、Magento 2、Laravel和headless commerce上交付电商平台，更广泛的技术栈还包括PrestaShop、OpenCart、Shopware、CS-Cart、Shopify、Salesforce、Akeneo、Odoo和Symfony。对于多供应商平台，选择通常归结为三种方案：

无论选择哪种基础架构，均应采用API优先设计，使供应商应用、合作伙伴数据Feed和AI服务与店面使用相同的接口。

安全与信任

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

测试验证：上线前需要测试什么

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

• 账本对账测试。针对多供应商购物车、佣金和手续费生成的测试数据，确认分成、退款和打款与服务商记录之差归零。
• 拆单测试。包含一个、多个及大量供应商的购物车，包括单行部分退款和取消的情形。
• 访问控制测试。自动化测试某一供应商尝试读取或修改其他供应商的商品、订单或打款记录，均须失败。
• 导入压力测试。在模拟买家流量的同时运行预期最大规模的供应商数据导入，检查页面响应时间是否维持正常。
• 打款失败测试。银行信息被拒、打款暂扣和纠纷情形下，余额须保持正确并可见。
• 排名与风控核查。AI搜索和欺诈评分在影响买家所见内容或供应商被暂扣之前，须与已标注的查询样本和历史案例进行比对验证。

案例：欧盟时尚科技平台

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

另有两个案例：RB Marketplace面向西非及海外侨民社区，将供应商审批、佣金和打款与基于平台API的客户端应用相结合。一个在线分类信息平台为一位匿名创始人所建，新增AI过滤功能，将违规广告标记供管理员审核。两者均未发布业绩数据。

本文的局限性

• 本文描述的是参考架构与通用实践；每个平台均需根据其供应商、商品和地区进行调整。
• 支付、税务和消费者法规因国家而异。DAC7和PCI DSS作为合规设计的示例引用，并非完整清单；请寻求法律和税务专业意见。
• Stripe Connect作为平台支付服务的一个例子列举，并非对其他服务商的比较推荐。
• 欧盟平台数据为该客户上线6个月内的自报结果；绝对数值未公开。

下一步

告知我们您的供应商模式、目录规模和支付地区，我们将预约方案评审，为您勾勒架构方案和首期发布计划。您也可以查看相关服务，了解Netbase JSC在零售与电商领域的实践，或浏览更多Netbase洞察。

相关服务与解决方案