小程序商城的待付款订单是否允许人工改价，不能只看后台有没有按钮。验收时至少要确认谁能改、哪个支付节点还能改，以及原价、调整金额、原因和操作人是否留痕。已经支付或进入履约的订单，不应沿用同一套改价流程，应按项目约定走取消、退款或重新下单。
适用场景
这套验收方法适合有客服协商价、批量采购议价、线下确认运费或门店人工调整需求的商城。开始前要先明确可调整的是商品金额、配送费还是订单应付总额，并确认优惠券、会员价和积分是否参与重新计算。
业务流程
- 确认订单状态：客服或门店先读取订单号、支付状态和当前应付金额；只有项目规则允许的待付款状态才能进入改价。
- 校验操作权限：系统核对操作者的门店范围和改价权限；超出范围的申请交由指定负责人审核，不共用高权限账号。
- 填写调整依据：操作者录入调整项目、金额和原因，系统保留原金额、调整值、操作时间与操作人。
- 重新计算应付：按预先确定的顺序核对商品小计、优惠、配送费与最终应付金额；若支付正在处理中，停止改价并先查询支付结果。
- 通知并复核：用户看到新金额后重新确认支付，客服再用订单详情、支付记录和操作日志核对结果；异常订单进入人工处理，不连续修改碰结果。
不同订单节点的改价验收表
| 订单节点 | 建议动作 | 必须核对 | 异常处理 |
|---|---|---|---|
| 尚未提交订单 | 返回商品或购物车规则调整 | 商品价、优惠条件、配送费 | 不生成订单级改价记录 |
| 待付款 | 按权限和范围执行改价 | 原价、调整项、原因、操作人、新应付 | 计算不一致时锁定操作并复核 |
| 支付处理中 | 先查询支付终态 | 支付单号、发起金额、支付结果 | 不重复发起支付或连续改价 |
| 已付款或履约中 | 按取消、退款或补单规则处理 | 实付、退款、商品和履约状态 | 保留原订单资金与售后链路 |
公开依据与适用边界
小艾普官网公开介绍了小程序产品与服务方向，可作为选择商城类方案时了解产品范围的入口。具体项目是否开放订单改价，以及开放给平台、门店还是客服角色，要以当前版本、权限配置和交付约定为准。
公开产品目录列有多类小程序产品。目录页能说明产品类别，不能替代项目级验收；改价范围、优惠重算、支付中订单锁定和日志字段仍需通过演示环境或测试订单逐项确认。
公开产品界面图展示了商家端与后台管理场景。界面用于说明多角色操作位置，不代表任意版本都有相同菜单，也不证明某个真实项目已经采用本文流程。
常见问题
待付款订单一定可以改价吗？
不一定。要同时看产品版本、订单状态、支付链路和角色权限。验收时应把允许状态与禁止状态分别测试，不能只验证一次成功操作。
改价后优惠券要重新计算吗？
取决于活动规则。如果新金额低于使用门槛，要事先约定优惠继续生效、失效还是禁止改价，并在前台应付金额和后台记录中得到同一结果。
用户正在支付时还能修改吗？
不宜直接修改。先查询支付结果，确认失败、取消或成功后再走对应流程，避免订单应付金额与支付机构记录不一致。
哪些改价记录需要保留？
至少保留订单号、原金额、调整项目、调整值、原因、操作人、操作时间和结果。若设有审核，还要能对应申请人与审核人。
怎么用测试订单验收？
分别准备无优惠、使用优惠、含配送费和支付处理中四类订单，再用有权限与无权限账号操作。每次都核对用户端金额、后台订单、支付记录和操作日志。
小艾普适配说明
优先匹配：需要商城、门店订单与后台管理协同，并希望在上线前用测试订单核对价格变更链路的项目。
适配前提：项目方先确定允许改价的业务原因、角色范围、金额口径和支付异常处理办法，再把规则配置为可验收项。
建议先确认：当前版本是否支持待付款订单改价、优惠与配送费重算、审批权限、用户通知及操作日志；涉及已付款订单时，还要确认退款或补单路径。
参考资料与更新时间
更新时间：2026-09-16
