> ## Documentation Index
> Fetch the complete documentation index at: https://waffo.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 按支付方式的退款限制

> 为什么同一个退款请求在一种支付方式上成功、在另一种上被拒绝：部分退款的可用性、退款窗口和截止时间、一个订单允许多少次退款、重复请求保护、请款前后的退款、已关闭的用户账户，以及被发卡行拒绝的卡退款。

[退款 FAQ](/docs/zh/support/refund-faq) 介绍适用于每一笔退款的规则：金额校验、幂等重试、跨币种换算、异步状态和手续费返还。本页回答在那之后出现的问题：\*\*为什么完全相同的请求在一种支付方式上成功、在另一种上被拒绝。\*\*跨币种计算见[汇率](/docs/zh/support/exchange-rates-faq)，涉及的错误码见[错误码与限制补充](/docs/zh/support/error-codes-and-limits-supplement)。

简短版本：\*\*退款能力是支付方式的属性，不是你账户的属性。\*\*同一账户上启用的两种方式、通过同一套集成扣款，退款行为可能完全不同。

## 为什么同一个退款请求在一种支付方式上成功、在另一种上失败？

因为每种支付方式带有自己的退款规则，Waffo 不会放宽它们。所有方式的 API 界面完全相同——差别在于该方式接受哪些请求。

下表按**支付方式类别**归纳我们看到的行为。把它当作你必须为之设计的差异形态，而不是特定方式的查询表：你账户上启用的方式的确切规则是你支付方式配置的一部分。

| 支付方式类别 | 全额退款 | 部分退款 | 多次部分退款 | 值得注意的限制 |
| - | - | - | - | - |
| 卡 | 是 | 取决于配置；部分卡配置仅支持全额退款 | 在部分退款可用的情况下 | 即使 Waffo 已接受请求，仍可能**被发卡行拒绝** |
| 电子钱包 | 是 | 通常是 | 通常是，有时需要先为你的账户启用 | 重复请求保护和请求之间的最小间隔 |
| 预付电子货币 | 是 | 是 | **否**——每笔原始交易一次退款 | 仅在原始交易后的固定窗口内可退 |
| 后付 / 信用（BNPL 类） | 是 | 是，用户账户处于活跃状态时 | 取决于方式 | 窗口与该方式的信用保留期挂钩；**已关闭的用户账户**阻止部分退款 |
| 银行转账 / 虚拟账户 | 取决于方式——有几种**完全无法通过 API 退款** | 同上 | 同上 | API 无法退款时，资金在支付方式之外返还（见[银行转账与虚拟账户](/docs/zh/support/bank-transfer-and-virtual-account-faq)） |
| 授权与请款分离的方式 | 是 | **仅在请款之后** | 请款之后 | 已请款支付的撤销有自己的截止时间，从支付起算 |

三个值得为之设计的后果：

1. 不要在你自己的代码里硬编码"该方式支持部分退款"。提交退款并处理拒绝。
2. 不要假定因为你账户上的一种方式支持某项能力，另一种也支持。
3. Waffo 已接受的退款仍可能以失败终态结束。

## 我启用的每种支付方式都能部分退款吗？

不是。部分退款是一项必须对特定支付方式可用**且**为你的账户启用的能力——它是你 Service → Payin 行上的 `Refundable` 列。当该行只允许全额退款时，部分退款请求会以 `A0014`（"Order cannot be refunded due to refund rules"）拒绝，而同一订单上的全额退款成功。当该行只允许一次部分退款而你请求第二次时，返回同一个码。

`A0017`（"Order cannot be refunded due to payment channel not supported"）是另一种失败：支付方式本身完全无法承载退款，因此部分和全额退款都无法通过。

当一种支付方式可能有多种行为时，**以最严格的选项为准**。实际上：

* 如果某方式对你的账户只能全额退款，即使该方式在别处能部分退款，部分请求也会失败。
* 如果某方式对你的账户只允许一次部分退款，即使第一次成功，第二次请求也会失败。

Waffo 不会悄悄把部分退款降级为全额退款，也不会把它排队稍后处理。如果你需要当前被拒绝的能力，请询问你的 Waffo 集成联系人是否可以启用——这是配置变更，不是你可以作为参数传入的东西。

## 一个订单能退多少次？

三个独立的上限同时适用，你会碰到最低的那个：

| 上限 | 值 | 超出时的错误 |
| - | - | - |
| Waffo 平台每订单最大值 | **50** 次退款 | `A0027` "The refund has exceeded maximum 50 times" |
| 金额 | 已退 + 进行中 + 本次请求 ≤ 原支付金额 | `A0003`——被视为参数失败，而不是退款规则违反 |
| 协议退款形态 | 从"仅一次退款"和"每订单一次部分退款"到无限次部分退款 | `A0014` |

有些方式起始为每订单恰好一次部分退款，可以从那里上调；少数方式对次数完全不设限。因为最低上限胜出，请把对账构建成把被拒绝的第二次退款当作正常分支，而不是事故。

## 退款有截止时间吗？

有，而且时钟总是从**原始订单**开始，而不是从你决定退款的那一刻。窗口是你账户上支付方式行的属性，你可以在两处读取而不是猜测：

| 位置 | 显示内容 |
| - | - |
| Service → Payin，`Refund Period` 列 | 该支付方式和币种的窗口 |
| 订单上的 `refundExpiryAt`（Order Inquiry） | 该订单的具体截止时间——由窗口推导，从订单创建日期起算，落在那一天的结束 |

形态因类别而异——预付电子货币和后付方式往往窗口最短，卡最长（受发卡行约束）——但数值是按方式、按账户的，所以不要把一种方式的窗口套到另一种上。

窗口关闭后退款会被拒绝——没有豁免。如果你的产品允许长期退货，请在发布政策之前检查你所接受方式的退款窗口，并在原支付之外处理迟到的退货。

## 我退了款，但订单的 `orderStatus` 没变，退款成功了吗？

很可能成功了。\*\*退款不会改变原订单的状态。\*\*原订单保持支付时到达的状态；退款是带有自己状态的独立记录，退款进度只出现在那里。

| 查看位置 | 看到的内容 |
| - | - |
| 对原订单调用 `/api/v1/order/inquiry` | 原始支付状态，不受退款影响 |
| 对退款调用 `/api/v1/refund/inquiry` | `REFUND_IN_PROGRESS` → `ORDER_PARTIALLY_REFUNDED` / `ORDER_FULLY_REFUNDED` / `ORDER_REFUND_FAILED` |
| 退款订单通知 | 退款的最终状态 |

所以"订单仍显示为已支付"不是退款丢失的证据。如果你的账务用原订单作为退款状态的键，它会看起来永远卡住——请改用退款记录作为键。

## 我立刻重发了一次退款，被当作重复拒绝了，有退出什么吗？

第二个请求大概率没有——这正是保护的目的。存在两种守卫：

* \*\*重复检测。\*\*有些方式会拒绝在短窗口内携带相同原始交易引用*且*相同金额的第二个请求——这在其他方面对部分退款次数不设限的钱包上很常见。
* \*\*最小间隔。\*\*有些方式要求同一订单上连续退款请求之间有短暂间隔。

两者都是防止意外双重退款的保护，所以不要把拒绝当作需要在紧循环中重试的失败。安全模式：

1. 重发*同一笔*退款时保持相同的 `refundRequestId`——它是幂等键，使重试无害。
2. 不要在同一订单上背靠背地发起真正的第二笔退款；让第一笔到达终态。
3. 两次尝试之间调用 `/api/v1/refund/inquiry`，而不是重发。

## 用户关闭或删除了账户，我还能给他退款吗？

不一定。在后付 / 信用方式上，**已关闭的用户账户会阻止部分退款**，且自关闭起超过规定时限后退款会被直接拒绝。全额退款通常在更长时间内仍然可行。

Waffo 没有办法绕过已关闭的账户：钱必须回到它来自的账户。如果退款因此被拒绝，请通过其他方式与用户结清。

## 我能在请款之前退款吗？

只能全额。在授权和请款是分离步骤的方式上：

| 订单状态 | 你能做什么 |
| - | - |
| 已授权，未请款 | **仅全额退款 / 取消**——没有部分退款 |
| 已请款 | 全额或部分退款，受该方式的部分退款规则约束 |
| 已请款，撤销中 | 撤销有自己的截止时间，从支付起算——读取订单上的 `refundExpiryAt` |

请款本身也有截止时间，且请款金额永远不能超过原授权金额。如果你需要返还一笔授权的一部分，请款你要保留的金额，而不是请款整笔授权再退差额。

## 为什么我账户上的一种方式只能全额退款，而另一种接受多次部分退款？

因为退款能力跟随**支付方式**，不是账户。一个账户上同时有一种仅支持全额退款的卡方式和一种接受多次部分退款的钱包方式，是很常见的。你的账户、合约类型或你调用的 API 都不会改变这一点。

设计上的含义很具体：你的退款 UI 和客服话术应该由订单所用的方式驱动，而不是单一的账户级规则。

## 有最小退款金额和最大退款金额吗？

最大值始终相同：**原支付金额**，减去已退和进行中的部分。没有任何支付方式允许你返还多于收取的金额；请求更多会以 `A0003` 拒绝。

最小值是人们实际会踩到的那个。它是该币种能表达的最小金额，在跨币种订单上则是*换算后*数字能表达的最小金额——这就是为什么一笔在你看来非零的退款可能被拒绝。如果换算后的金额为零或以下，退款以 `A0014` 拒绝；见[限制、币种与配置错误](/docs/zh/support/error-codes-and-limits-supplement)。

跨币种订单的一个有用习惯：按原订单的**比例**退款，而不是按你自己币种的绝对数字，这样换算后的金额随原支付缩放，而不是被四舍五入掉。

## 退款显示成功，但用户说钱没到

两种说法可以同时成立。退款成功意味着**退款请求已成功完成**——不意味着资金已经到达用户账户。退款的结算以该成功结果为键，而不是用户的余额。

实际上大多数方式上资金很快跟进，但这两个事件是不同的，其间隔不在 Waffo 控制之内：

| 你观察到的 | 它告诉你的 |
| - | - |
| `ORDER_FULLY_REFUNDED` / `ORDER_PARTIALLY_REFUNDED` | 退款已被支付方式接受并处理 |
| 用户的余额 | 支付方式或银行自己的入账时间 |

所以支持话术是"退款已经通过；多快显示取决于用户的银行或钱包"。只有当退款已处于成功终态相当长时间而用户仍看不到时，才升级到 Waffo 支持——并带上原订单 ID 和退款 ID。

## 退款以 `ORDER_REFUND_FAILED` 结束，发生了什么，我该怎么做？

`ORDER_REFUND_FAILED` 是**终态**——钱没动，在该退款记录上也不会再动。卡支付上最常见的原因是在 Waffo 已接受请求之后**发卡行拒绝了退款**，这就是为什么失败是异步到达的，而不是作为 API 错误。

怎么做：

1. 读取退款订单通知或 `/api/v1/refund/inquiry` 了解原因。
2. 不要用相同的 `refundRequestId` 重发并期望不同结果——终态不会重新打开。
3. 如果拒绝无法用金额、窗口或该方式的规则解释，请带上原订单 ID 和退款 ID 向 Waffo 支持提出。因你无法控制的原因失败的退款按个案处理。
4. 当卡完全无法入账时，通过其他途径与用户结清。

## 这些限制中哪些适用于我，我在哪里查？

提交之前没有单一的"退款能力"字段可读。你可以依赖的：

* **Merchant Portal → PayIn** 页面列出你账户启用的支付方式，及其币种和金额限制。
* `/api/v1/paymethodconfig/inquiry` 以编程方式返回同样的配置。
* 退款 API 的拒绝是针对具体请求的权威答案：`A0014` 表示协议的退款规则不允许（形态、次数、窗口，或换算后为零的金额），`A0017` 表示支付方式完全无法承载退款，`A0027` 表示达到了平台次数上限，`A0003` 表示金额超过剩余可退额，或必填退款字段缺失且在响应中列出。

因此，稳健的集成模式是**先尝试，再分支**——而不是**先预测，再尝试**。

## 接下来看哪里？

| 问题 | 页面 |
| - | - |
| 通用退款规则、批量退款、手续费返还 | [退款 FAQ](/docs/zh/support/refund-faq) |
| 跨币种订单的退款金额 | [汇率](/docs/zh/support/exchange-rates-faq) |
| 银行转账的多付与少付 | [银行转账与虚拟账户](/docs/zh/support/bank-transfer-and-virtual-account-faq) |
| 稳定币退款与必填的退款地址 | [稳定币异常与退款](/docs/zh/support/stablecoin-exceptions-faq) |
| 每个退款相关错误码的含义 | [错误码与限制补充](/docs/zh/support/error-codes-and-limits-supplement) |


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.