微信公众号支付退款返回REFUND_FEE_NOT_EQUAL，退款金额到底哪里不对？

微信支付退款接口的报错信息里，REFUND_FEE_NOT_EQUAL 属于金额校验失败。这个错误码并不只是在两个数字不一致时才出现，很多情况下，因为接口字段的单位是分、参数签名前经过了字符串转换、或者同一笔订单已经产生过部分退款，最终传给微信的 refund_fee 与系统记录的应退金额发生偏差，就会直接返回该码。要解决它不能只看订单展示金额，必须回到微信支付的金额模型和退款单累计规则上。

全额退款与部分退款的不同校验边界

在微信支付退款的接口定义中，total_fee 表示原订单的支付金额，refund_fee 表示本次申请退款的金额，两者的单位都是分。平台校验 REFUND_FEE_NOT_EQUAL 时，核心就是判断 refund_fee 和 total_fee 以及历史退款记录之间的关系。如果商户走的是全额退款，那么 refund_fee 必须和原订单的 total_fee 完全相等，多一分或者少一分都会被拒绝。比如订单实付 1 元，即 100 分，退款接口里传 refund_fee=100 可以成功，但传 refund_fee=99 会认为金额不相等，传 refund_fee=101 会超过可退金额，通常也表现为金额校验失败。

部分退款时的规则则略有不同：本次退款金额必须大于 0，并且必须小于或等于订单剩余可退金额。微信侧会读取该商户订单号已经成功退款的累计金额，再用原订单总金额减去累计退款金额，得到剩余可退上限。本次 refund_fee 只有落在这个区间内才能通过。问题在于，很多业务系统只在前端页面上做粗略校验，比如退款金额不能大于订单金额，却没有维护历史退款累计值。第一次退 40 元成功，第二次再退 70 元时，单看 70 小于 100 元是合理的，但实际上已经超过剩余 60 元，接口就会抛出 REFUND_FEE_NOT_EQUAL 或相关错误。

还有一个容易混淆的点：微信支付校验的是订单原始金额，而不是商户优惠后的实收金额。如果订单用了微信支付渠道的代金券或商家券，原订单的 total_fee 可能大于用户实际支付金额。商户如果误把优惠后的金额当成 total_fee 来算全额退款，就会因为差额触发该类错误。正确做法是从微信订单查询接口中取回支付单的真实金额，或者在支付成功后存储微信返回的总额，而不是依赖业务订单里的营销计算值。

金额单位与小数换算的隐藏陷阱

微信支付接口的金额字段是整数分，这本来是为了避免小数精度问题，但很多系统内部的金额存储用的是元，调用前才做乘 100 转换。如果转换方式不严谨，就会在这个环节产生误差。BigDecimal 几乎应该成为金额处理的标准工具，但仍有不少项目直接使用 double 或 float。例如订单金额 0.58 元，在 Java 中执行 0.58 * 100 得到的结果并不是精确的 58，而可能是 57.99999999999999，强制转成整数后就变成 57 分。退款时少 1 分钱，就会直接报 REFUND_FEE_NOT_EQUAL。

除了浮点计算，字符串格式化也会造成隐式错误。有些开发者在构造请求参数时使用 String.format("%.0f", amount) 或者 DecimalFormat，如果金额是 0.1 元，某些语言或环境可能因为四舍五入策略不同产生偏差。正确做法是在整个支付链路里把金额统一为整数分存储，数据库字段使用 bigint，接口入参和出参都用分。如果必须从元转换，推荐使用 BigDecimal.valueOf(amount).movePointRight(2).intValueExact() 这类方法，让精度异常直接抛出而不是悄悄截断。

import java.math.BigDecimal;

public class AmountConvert {
    public static int yuanToCent(String yuanAmount) {
        // 使用字符串构造 BigDecimal，避免二进制浮点误差
        return new BigDecimal(yuanAmount)
                .movePointRight(2)
                .intValueExact();
    }

    public static void main(String[] args) {
        int totalFee = yuanToCent("0.58");
        int refundFee = yuanToCent("0.58");
        System.out.println(totalFee + ":" + refundFee);
        // 输出应当是 58:58，而不是 57:58
    }
}

如果商户系统里有多个服务同时处理金额转换，建议把转换逻辑封装成公共 SDK 或工具类，避免每个服务各自写一套。曾经有案例，订单服务按分存储，退款服务从业务库读到元后自己乘 100，因为数据类型是 double，退款金额变成了 99 分，测试环境金额较小可能碰巧通过，上线后订单金额变大就出现随机 1 分钱的差额。这类问题必须通过代码审查和统一工具类解决。

多次退款与并发场景下的累计金额校验

微信支付支持同一笔订单多次部分退款，但累计退款不能超过原订单总额。这个累计值不是商户自己说了算，而是微信侧根据已经受理成功的退款单计算。商户本地如果没有同步维护累计退款金额，就可能在同一时刻发起两笔退款，两笔单看金额都合法，但合计超过订单总额。尤其是分布式系统里，两个退款请求同时打到不同服务节点，都读到了旧的剩余可退金额，就会同时通过本地校验，最终在微信侧被拦下来。

要解决这个问题，不能只依赖接口返回后更新本地状态，因为微信调用是网络请求，存在响应超时和重试。一个更稳妥的方案是在退款单表上增加 refunded_amount 字段，并用数据库行锁或乐观锁控制同一订单号的并发退款。比如在事务里先查询订单剩余可退金额，再插入退款申请记录，提交事务后再调微信接口。如果接口返回成功，更新退款状态；如果返回失败，回滚本地记录或标记为失败并释放冻结金额。这样能尽量避免本地先扣减后微信失败的复杂补偿逻辑。

排查 REFUND_FEE_NOT_EQUAL 时还要关注退款单是否已经存在。很多商户在退款按钮上做了防重复，但用户双击、网络重试、定时任务重试等仍然可能产生新的退款单号。虽然同一 out_refund_no 是幂等的，但如果每次重试生成新的退款单号，第一笔已经成功后，第二笔就相当于额外退款。看到该错误时，第一步应该查微信支付退款查询接口，确认该订单已经有哪些退款单，累计退了多少，而不是反复修改金额后盲目重试。微信侧数据永远是最终裁判。

退款参数构造与对账建议

构造退款参数时，除了保证金额正确，还要注意金额字段必须转换成整数分字符串，不能带有小数点、科学计数法或空格。以下是一个简单的参数组装示例，实际项目中还需要补充签名逻辑。这里将 total_fee 和 refund_fee 都按分传入，并且要求调用方在传入前完成本地校验。

import java.util.HashMap;
import java.util.Map;

public class RefundParams {
    public Map<String, String> buildRefundParams(
            String outTradeNo,
            String outRefundNo,
            long totalFee,
            long refundFee) {

        validateAmount(totalFee, refundFee);

        Map<String, String> params = new HashMap<>();
        params.put("appid", "wx8888888888888888");
        params.put("mch_id", "1900000109");
        params.put("out_trade_no", outTradeNo);
        params.put("out_refund_no", outRefundNo);
        params.put("total_fee", String.valueOf(totalFee));
        params.put("refund_fee", String.valueOf(refundFee));
        params.put("nonce_str", System.currentTimeMillis() + "");
        return params;
    }

    private void validateAmount(long totalFee, long refundFee) {
        if (totalFee <= 0) {
            throw new IllegalArgumentException("total_fee must be positive");
        }
        if (refundFee <= 0) {
            throw new IllegalArgumentException("refund_fee must be positive");
        }
        if (refundFee > totalFee) {
            throw new IllegalArgumentException("refund_fee exceeds total_fee");
        }
        if (refundFee != totalFee) {
            // 部分退款需要额外校验历史已退金额，这里只做单笔上限检查
            System.out.println("partial refund, please check refunded_amount");
        }
    }
}

最后是日常对账。微信支付的资金流水以分记账，商户系统如果使用小数、字符串、整型混用，时间一长就会出现尾差。建议每天拉取微信支付账单，按订单号和退款单号核对支付金额、退款金额、退款状态。金额字段在数据库里统一使用 bigint，对账时也用整数分计算。不要等到客服接到用户投诉才去查差异，主动对账能更早发现浮点转换、并发超退、重复退款等问题。接口报错只是最后一道防线，真正可靠的是业务系统内部对金额生命周期的严格管理。

总结一下，REFUND_FEE_NOT_EQUAL 这个错误看起来是金额不相等，实际暴露的往往是金额单位不统一、累计退款没有精确维护、或者退款参数取自错误数据源。修复时先确认原订单真实金额，再检查本次退款金额和历史已退金额的累计关系，最后把所有金额统一为整数分并加入自动化校验。完成这三步后，大部分退款失败都能在代码层直接定位。

微信支付退款REFUND_FEE_NOT_EQUAL退款金额校验修改时间：2026-09-27 11:38:44