> ## 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. # 退款的钱从哪里来 > 退款实际从你的哪个 Waffo 余额中扣、按什么顺序、为什么结算刚打款后退款会因余额不足失败、退款备用金账户如何避免这种情况，以及为什么这一切都不改变退款 API。 退款是把钱从你的 Waffo 余额中**转出**，所以它可能因为一个 与原订单毫无关系的原因失败：没有钱可扣。 本页解释使用哪个余额、按什么顺序，以及退款因资金 被拒时该怎么做。 关于退款的其他一切——部分退款、重试、跨币种 金额、手续费退还——请参见[退款 FAQ](/docs/zh/support/refund-faq)。关于每个 余额是什么，请参见 [余额与账户历史](/docs/zh/support/balance-and-account-history-faq)。 ## 退款从哪个余额扣？ 按以下顺序。第一个能覆盖退款的来源被使用，查找 到此停止： | 顺序 | 来源 | 条件 | | - | - | - | | 1 | **待结算余额** | 其可用余额**包括该账户上的任何透支额度**能覆盖退款 | | 2 | **退款备用金账户** | 你对该商户账户、主体和币种有生效的退款备用金安排，**并且**该账户的可用余额包括其自身的透支额度能覆盖退款 | | — | 两者都不能 | 退款以 `A0012` 被拒绝——*Insufficient merchant account balance* | 决定大多数实际情形的三个细节： * **透支是第 1 步的一部分，不是单独的一步。** 你的待结算 账户带有透支额度，第 1 步的检查已经把它算进去了。 所以退款可以成功并把该余额推到负数——这是 设计行为，负数会被你后续的入账 交易抹平。 * **退款备用金账户是兜底，不是首选来源。** 只有当 待结算余额及其透支额度都耗尽后才会 用到它。 * **退款备用金这一步以生效的安排为前提。** 如果该币种没有生效的 退款备用金安排，就没有第 2 步——第 1 步无法覆盖时 退款立即失败。 ## 检查的是哪个币种的余额？ 退款所用的那个币种。余额检查是**按币种**进行的，针对 你的商户账户和法律主体以该币种持有的账户。 如果你用多个币种交易，这一点很重要：一个币种的余额充足 对另一个币种的退款毫无帮助。资金不会在币种之间 划转来覆盖退款，上述选择中也没有跨币种兜底 ——某个币种余额为空时，该币种的退款会失败， 即使你其他币种资金充足。 退款备用金账户也同样：生效安排的检查 是针对该特定币种的，所以覆盖一个 结算币种的退款备用金安排不延伸到另一个币种。 ## 为什么结算后第二天退款就因余额不足失败了？ 因为结算把退款所依赖的余额清空了。 你的资金在结算日之前停留在待结算余额中， 然后转出到你的结算账户，再到你的银行。一旦结算 执行，待结算余额可能为**零**或接近零——此时 请求的退款除了透支额度之外没有任何可扣的。 这就是为什么退款失败集中出现在结算打款之后，也是为什么 在原订单几周前已成功结算的情况下它们看起来莫名其妙。 订单没问题；余额是空的。 你的选项： | 选项 | 效果 | | - | - | | 等待新交易 | 入账支付把待结算余额补回来，之后重试退款就会成功 | | 给待结算余额充值 | 经典解法——但这意味着每次时机不巧就要做一次资金划转 | | 设立**退款备用金账户** | 预先为一个专用于退款的账户注资，上述第 2 步就会覆盖你，无需逐次处理 | 退款备用金账户的存在正是为了消除"等待还是充值"的选择：它 是预付的，只用于退款，并且带有自己的透支 额度。请与你的 Waffo 账户经理讨论是否值得为你的退款量 设立一个。 ## 退款因资金失败了，我可以直接重试吗？ 可以。资金不足的拒绝发生在**退款订单创建之前**， 作为预检——所以没有任何记账，没有半途而废的状态， 没有需要清理的东西。原订单未受影响，其 可退金额不变。 因此重试是安全的，也是常规的解决办法：资金 可用后重试一次。遵循你对任何退款重试都会采用的幂等做法， 以确保模糊响应后的重试不会造成重复退款——参见 [退款 FAQ](/docs/zh/support/refund-faq)。 重试**不会**做的是排队。无法获得资金的退款没有 待处理状态：它被直接拒绝，当你的余额之后恢复时 不会自动发生任何事。如果你需要资金一到就 把退款发出去，你必须自己重新发起。 ## 有透支额度是不是意味着退款永远不会失败？ 不是。透支额度是一个限额，不是没有限额。 每一步的检查都是*余额加上该账户的透支额度* 对比退款金额——所以大于该合计数字的退款仍然 失败，且以同样的方式失败，即 `A0012`。额度给你的是 对刚被结算清空的余额这一常见情形的容忍； 它不是无限的信用线。 两个后果： * 一笔大额退款可能失败，而同一账户上的小额退款成功。 检查是按每笔退款、针对全额进行的——退款不会从一个来源部分 出资再从另一个来源补足。 * 一旦待结算余额为负，剩余额度就更小， 后续退款的空间更少。针对空余额的一批 退款会在中途开始失败，而不是全部 同时失败。 ## 这一切会改变我的结算或提现吗？ 不直接改变，但负的待结算余额有值得了解的连带影响。 * **结算**：无论由哪个账户出资，退款都作为 `REFUND` 交易净额计入你的结算计算。如果某个周期的退款 超过其支付，该周期净额为负并结转——参见 [结算计算详解](/docs/zh/support/settlement-calculation-explained)。 * **提现**：提现从你的结算账户扣款，而不是 待结算余额，所以退款不会直接减少你今天能 提现的金额。它减少的是之后将结算进入该账户的金额。 ## 我能选择退款从哪个余额出吗？ 不能，也不需要。选择完全在服务端进行。 * 退款 API 的**请求字段不变**——没有资金来源的 参数，你的集成无需添加任何内容。 * 退款 API 的**响应字段不变**——所选来源不会 在创建退款响应或退款查询中返回。 * 无论你通过 API、批量退款文件还是商户 Portal 退款，行为都相同。 实际的后果：**如果你已经集成了退款，退款备用金 账户完全不需要你改代码。** 它改变的是钱从哪里 来，而不是你如何请求。 退款 API 上确有一个字段容易被误认为与此相关： `refundSource` 描述的是**谁发起**了退款（你，或者可以代表你 自动退款的争议预防服务之一）。它与 由哪个余额出资无关。 资金来源在事后会变得可见，在你的 对账数据中：结算和账务记录会区分由待结算余额 出资的退款和由退款备用金账户 出资的退款，所以对账时你可以分辨它们。 ## 批量退款检查余额的方式不同吗？ 不——批量退款在退款订单创建之前按行运行同样的检查。 无法获得资金的行以同样的资金不足 条件被拒绝，而不是排队等待。 对批量规划的影响是，你应该按**上传时的 待结算余额加透支额度加退款备用金余额**来确定批次规模， 而不是按你要退款的订单总值。关于被拒绝的行 如何影响批次的其余部分，请参见[退款 FAQ](/docs/zh/support/refund-faq)。 ## 退款能从我的合同保证金里出吗？ **合同项下持有的滚动或固定保证金**与退款备用金账户是 不同的东西，尽管名称相似： | | 退款备用金账户 | 合同保证金（滚动 / 固定） | | - | - | - | | 用途 | 预先注资的退款来源 | 合同项下扣留的风险保障 | | 谁注资 | 你，通过充值 | 从每次结算中自动扣留 | | 是否自动扣出 | 是，作为退款兜底 | 否 | | 在哪里看到 | 退款对账记录 | Portal **保证金账户**模块 | 关于合同保证金，请参见[保证金账户](/docs/zh/support/reserve-faq)。注意 支持工单中这两者经常被混用——如果有人告诉你 "你的保证金可以/不可以用于退款"，请先确认指的是哪一个。 ## 拒付的钱从哪里扣？ 拒付及其拒付手续费在**结算时从 你的待结算余额**扣除，两者走同一条路径—— 手续费的出资方式与金额没有区别。 因为该余额可透支，拒付不会像退款那样被空余额 阻止：它被允许把余额推到负数， 负数由之后的入账资金抹平。如果整个结算周期的净额 为负，当天不会有资金流动，金额结转——参见 [结算计算详解](/docs/zh/support/settlement-calculation-explained)。 拒付也不会动用合同保证金。 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.