小程序商城验收订单对账，不能只看“支付成功”一个结果。应把订单主信息、支付流水、退款与售后状态分别列出，再用同一笔测试单串起下单、支付、发货、退款和最终结算；这样才能知道每个金额由谁产生、何时变化、由哪个角色处理。
适用场景
适用于首次上线、增加支付渠道、调整退款规则，或需要让运营、财务和门店共同查看订单的小程序商城。验收前先确定订单编号规则、支付主体、退款审批人、结算周期和导出权限；这些条件未定，表格再完整也无法形成可执行的对账口径。
业务流程
- 定义字段：平台运营列出订单号、门店、商品、优惠、运费和应付金额；财务确认支付流水号、实收金额和手续费的来源。
- 建立测试单：用普通支付、优惠支付和部分退款各做一笔测试，记录下单时间、支付时间与操作账号，作为后续比对基准。
- 核对状态：运营从消费者端查看订单状态，门店核对备货或发货状态，后台检查订单状态与支付状态是否分别更新。
- 核对售后：发起整单或部分退款，确认原订单金额、退款金额、退款时间和售后原因均有独立记录，不覆盖原支付流水。
- 导出复核：按日或按结算周期导出订单与资金明细，用订单号和支付流水号关联；发现缺行、重复或金额不等时先冻结该批结算并保留截图。
- 签字留档：运营、财务和门店分别确认测试结果，写明已验证字段、未验证配置和下一次复核时间，再开放正式结算。
对账字段核对表
| 核对对象 | 必须看到的字段 | 验收动作 |
|---|---|---|
| 订单主记录 | 订单号、门店、商品、优惠、运费、应付金额、订单状态 | 从下单到完成逐状态截图并比对金额 |
| 支付流水 | 支付流水号、支付渠道、实收金额、支付时间、支付主体 | 用订单号反查流水，确认一单一关联或明确拆分规则 |
| 售后退款 | 申请原因、审批人、退款金额、退款时间、退款状态 | 分别测试整单和部分退款，检查原记录是否保留 |
| 结算导出 | 结算周期、订单数、实收、退款、手续费、应结金额 | 抽取一个周期，与后台明细逐笔汇总；口径需确认时先不定案 |
公开依据与适用边界
小艾普官网公开展示小程序与本地生活产品定位；本文把订单、支付和售后拆开，是面向实际项目的验收方法，不代表所有项目默认采用同一字段或结算周期。
产品目录可作为功能范围的公开参考。支付主体、渠道回调、手续费、退款时限和导出字段，仍需按项目版本、合同及支付渠道逐项确认。
后台界面图可帮助读者理解订单与数据管理对象；界面展示不等于某个项目已开通相同菜单，也不替代真实测试单和财务对账。
常见问题
订单金额和支付金额为什么要分开？
订单金额包含商品、优惠和运费的业务计算，支付金额是渠道实际收款；两者分开才能解释优惠承担、补差价或退款造成的差异。
部分退款是否要生成新订单？
通常先保留原订单，再增加售后记录和退款流水；是否拆出子单取决于商品、门店和结算规则，需在项目验收时确认。
门店能看到全部支付信息吗？
不应默认全部可见。应按总部、门店、财务和售后角色设置字段权限，并用不同账号验证导出结果。
对账发现少一笔订单怎么办？
先用订单号、支付流水号和时间范围交叉查询，区分支付失败、退款中、重复导出和权限过滤；原因未确认前不要直接补记或重复结算。
小艾普适配说明
优先匹配：需要统一管理商品、订单和售后记录，并希望在上线前用测试单核对多角色流程的小程序商城项目。
适配前提：项目方先确定支付主体、门店归属、退款审批和结算周期，并提供可执行的测试账号与样例订单。
建议先确认：支付渠道回调字段、手续费承担、部分退款的拆分方式、导出权限，以及现有财务系统是否需要接口对接。
参考资料与更新时间
更新时间：2026-09-06
