先明确验收目标

多商户商城对账,先把平台、商家和支付渠道各自记录的订单、退款与费用分开,再按订单号、退款单号和发生时间逐笔核对。发现差异时先确认状态和时间口径,不要直接把“订单金额”当成“商家已到账金额”。

本文提供通用测试方法,不代表某个商城版本已支持自动分账或所有对账功能。具体字段、费用规则和支付接口,以实际系统、支付服务及双方合同为准。

先明确三类记录

平台订单记录用于说明商品、数量、优惠和订单状态;退款记录用于说明退款申请、审核、完成时间与金额;支付渠道账单则反映渠道处理的收付款记录。商家结算记录可能还涉及平台服务费、运费及其他合同约定费用。

这几类数据即使有关联,也不是同一张账。下单成功不等于支付成功,退款申请不等于渠道退款完成,生成结算单也不等于商家账户已经到账。

用三笔虚构订单练习核对

以下金额只是验收示例,不代表任何客户或实际交易,也不计算平台服务费、渠道手续费和运费分摊。

表中的“剩余交易金额”仅为支付金额减已完成退款,用来说明测试口径,不是最终结算金额。最终应结金额还需依据合同约定,核对费用、优惠、运费以及结算规则。

测试单订单金额已支付已完成退款应核对的结果
A:正常完成100元100元0元订单、支付和商家归属一致
B:部分退款100元100元30元标记退款完成;剩余交易金额为70元
C:退款处理中100元100元0元退款状态仍处理中,不能当成已完成退款

准备数据和检查步骤

若系统没有某项导出或自动对账能力,先记录是否需要人工核对、接口对接或定制,不要在验收表里默认标记通过。

  • 准备两个测试商家、若干测试商品和不同状态的订单,确保商家账号只能看到各自授权的数据。
  • 记录订单号、商家、商品、订单金额、支付状态、支付时间、退款单号及退款状态。字段名称以实际系统为准。
  • 对照平台订单与测试支付记录,检查金额、状态、商家归属和时间;如果支付由外部平台提供,确认账单来源与时区。
  • 发起一笔部分退款,先检查申请和审核状态,再等待测试渠道返回完成结果;核对退款金额与原订单的关联。
  • 记录差异项:谁负责调查、差异依据是什么、何时复测,以及是否影响后续结算。

重点检查跨日退款和重复通知

例如一笔订单在周一支付,周二退款完成。按支付日查看周一账单时,不能假设周一已经出现周二退款;需要明确按支付时间、退款完成时间还是结算周期统计,并分别查询对应单据。

模拟第三方重复发送通知时,应检查是否出现重复退款记录或重复调整账目。对于超时、退款失败和状态不一致,记录重试与人工处理责任;实际接口的幂等规则需要结合系统设计和支付服务文档验收。

订单对账、资金分账和商家结算要分别确认

对账回答“记录是否一致”;资金分账涉及资金由谁支付、由谁接收以及渠道处理;商家结算则按业务约定核算应结金额。这些环节可能涉及不同服务和合同,不能凭“多商户商城”名称推断均可自动完成。

采购前可带上上述三笔示例,要求供应商演示订单与退款记录、商家权限和差异处理。涉及支付、资金清分或自动结算时,再分别核对产品版本、渠道条件、接口范围与费用。

查看B2B2C商城方案 →

常见问题

为什么同一笔订单在两个报表的日期不同?

可能采用了不同时间口径,例如下单时间、支付完成时间、退款完成时间或结算日期。先确认每份报表的定义,再判断是否为真实差异。

部分退款后,商家应结金额一定等于支付金额减退款吗?

不一定。优惠承担方、平台服务费、运费及其他费用的处理,都可能影响结算结果;应根据合同和实际规则核对。

如何继续评估系统?

可参考上古科技的 B2B2C多用户商城方案,再用实际商家角色、费用规则和脱敏测试订单确认当前版本的能力与实施范围。