退货界面显示退款总额，不等于说明钱退到了哪种支付方式。委托网站团队制作退款流程前，经营者应先确认分配规则以及每一笔的证据，而不是只验收总金额。
官方依据与范围
Shopify说明了部分退款优先退礼品卡，以及原卡停用后的新卡路径。 官方参考 · 2026年10月17日核对.
已填写的合成验收例子
合成教学例子，不是真实客户案例。示例配置不是对任何真实店铺的测评；窄屏可横向滚动表格。
| 输入 | 核对口径 | 预期 |
|---|---|---|
| 礼品卡80＋银行卡120；批准退110 | 礼品卡原可退部分80 | 卡80；银行30 |
| 原卡已经停用 | 不能向原卡充值 | 需要替换方案批准 |
| 界面显示退110；缺银行凭证 | 金额不是结算证据 | 银行部分仍未核验 |
可执行的交付检查
- 记录原支付分账、可退额度、卡状态与网关，订单资料须脱敏。
- 对照批准的分配，分别测试退款少于及超过礼品卡部分的情形。
- 逐笔核对支付记录和更新余额，未完成部分明确标为待处理。
怎样解释输出
合成例子的80加30能对上110，但不能证明退款已经执行。通知、新的支付凭证和银行卡结算是不同输出，应要求供应商提供按支付方式拆开的验收列，而不是一个“退款成功”标签。
明确的适用边界
不提供到期法律判断，不执行付款或改余额，不保证任意网关支持充值退款。实施前核对实际网关及可退限制。
复核有限教学模型
保存两份文件到同一目录，用Node22或更新版本运行下面命令。JSON保留明确输入与预期，脚本只处理这些合成数据，无网络、密钥、付款或API调用。通过只证明有限模型与预期一致，不证明真实集成。
node check.mjs gift-refund-allocation-acceptance.json