uni-app调用退款接口前必须确认：①退款由后端调用微信/支付宝官方接口完成，前端仅触发申请；②不可在uni.requestPayment中传refund参数；③需通过轮询后端状态接口获取结果，且后端必须正确处理回调通知并更新数据库。
uni-app 调用退款接口前必须确认的三件事
退款不是前端发起就能退，而是必须由后端调用微信/支付宝官方退款接口完成。uni-app 前端唯一能做的，是触发「退款申请」请求，并等待后端返回处理结果或轮询状态。常见错误是直接在 uni.requestPayment 里传 refund 参数——这根本不存在，uni.requestPayment 只用于支付，不支持退款。
实际流程中，前端只需做三件事：
- 用户点击「申请退款」时，调用你自己的后端退款接口（如
/api/refund/apply），传入订单号out_trade_no和退款金额refund_amount - 后端收到请求后，用商户证书、私钥等调用微信
/v3/pay/transactions/out-trade-no/{out_trade_no}/refunds或支付宝alipay.trade.refund接口 - 前端不等待退款完成，而是跳转到「退款详情页」，通过轮询
/api/refund/status?out_trade_no=xxx获取当前状态
微信退款接口调用失败的典型错误码与含义
后端调用微信 v3 退款接口时，前端可能间接收到这些错误响应，需做好对应提示：
-
400+INVALID_REQUEST：参数缺失，比如没传out_trade_no或refund_amount小于等于 0 -
404+RESOURCE_NOT_EXISTS：原支付单号查不到，可能是订单未支付成功、已被全额退款、或已超 365 天有效期 -
422+REFUND_FAILED：余额不足、账户异常、或原交易被冻结，此时退款无法进行 -
401+INVALID_SIGNATURE：签名错误，多因证书路径错、私钥格式非 PKCS#8、或时间戳偏差超 5 分钟
注意：refund_amount 单位是「分」，且不能超过原订单 amount.total；同一笔订单多次退款，累计金额也不能超限。
Temu欧洲站-退货退款
下载
Temu 欧洲站电商退货退款API，通过 LinkFox 网关转发 Partner EU Returns & Refunds / 售后退货退款 相关后台/Temu 接口（退货申请、退款、售后单查询与处理等），接口将按 Partner 文档逐条接入。当用户提到 Temu EU 退货、退款、售后退货、return...
uni-app 中轮询退款状态的轻量实现方式
不要用 setInterval 无脑轮询，容易被节流或触发风控。推荐带退避策略的递归调用：
const pollRefundStatus = (outTradeNo, attempt = 1) => {
uni.request({
url: '/api/refund/status',
data: { out_trade_no: outTradeNo },
success: (res) => {
const { status } = res.data
if (status === 'SUCCESS' || status === 'CLOSED') {
uni.showToast({ title: '退款已完成', icon: 'success' })
return
}
if (attempt < 5) {
setTimeout(() => pollRefundStatus(outTradeNo, attempt + 1), Math.min(1000 * attempt, 5000))
}
}
})
}
关键点：
- 最多尝试 5 次，间隔从 1s 逐步拉长到 5s
- 后端
/refund/status接口应只返回必要字段：如status（PROCESSING/SUCCESS/CLOSED/ABNORMAL）、refund_time、refund_fee - 若状态为
ABNORMAL，前端应引导用户联系客服，而不是重试
退款回调通知为什么不能只信前端轮询
微信/支付宝的退款结果通知（refund_notify_url）是异步到达后端的，它比前端轮询更权威、更及时。但问题在于：这个通知可能延迟数秒甚至几分钟，也可能重复发送。所以后端必须做到两件事：
- 对每条回调做幂等校验（用
out_refund_no做数据库唯一索引或 Redis setnx） - 无论是否收到回调，都允许前端按需轮询；但最终订单状态更新，必须以回调为准
这意味着：前端看到「退款中」是常态，看到「已到账」却不能仅靠轮询判断——它依赖后端把回调结果落库后，再被轮询接口读出。最容易被忽略的是：没在回调里更新数据库的 refund_status 字段，导致前端永远轮询不到 SUCCESS。
