> ## 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.

# 结算账户结构与账户历史筛选

> 为什么一个结算币种会显示两个账号、为什么一笔提现会分成两笔付款到账，accountSubType 和透支额度字段是什么意思，以及账户历史正确的筛选值——覆盖结算账户和保证金账户的六种业务类型，包括保证金扣留、释放和调整。

[余额与账户历史](/docs/zh/support/balance-and-account-history-faq) 解释了每种余额的含义，以及为什么可提现金额可能低于结算余额。
本页介绍这些余额底下的账户结构：为什么一个结算币种会出现多个账号、为什么一条提现指令会分成两笔付款到账，
以及账户历史实际接受哪些筛选值。提现 API 本身请参阅
[提现与余额 API](/docs/zh/support/withdrawal-and-balance-api-faq)。

## 为什么同一个结算币种在 Portal 里显示两个账号？

因为结算账户可以拆分为两个子账户，如果您的账户是拆分的，Portal 会把两个都展示给您。每个账户带有一个 `accountSubType`：

| `accountSubType` | 含义 |
| - | - |
| `REGULATED` | 受监管子账户 |
| `CORPORATE` | 企业子账户 |
| `REGULATED_CORPORATE` | **合并**账户——一个账号同时承载两者，不拆分 |

三种类型中哪一种适用于您，取决于您的账户开设时的设置；这不是您可以自行更改的配置。有两点值得记住：

* 如果是 `REGULATED_CORPORATE`，每个币种您只会看到**一个**账号，一切都按单个资金池处理。
* 如果是分开的 `REGULATED` 和 `CORPORATE` 账户，同一币种您会看到**两行**，每行有自己的账号和自己的可用余额。
  您在该币种的总头寸是两者之和——没有任何一行单独显示这个总数。

账户视图把它们作为挂在币种级账户下的 `subAccounts` 列表返回，所以 `subAccounts` 列表非空的行是父账户，其余额明细在子账户里。

## `overdraftLimit` 和 `availableOverdraftLimit` 是什么？

每个账户可以带有一个透支额度，用两个字段返回：

| 字段 | 含义 |
| - | - |
| `overdraftLimit` | 为该账户配置的透支额度总额 |
| `availableOverdraftLimit` | 该额度中尚未使用的部分 |

这两个字段解释了余额为什么可以在一切正常的情况下变为负数：拒付和拒付手续费会按固定顺序尝试从您的各个余额中扣除，
到该顺序的最后一步时可能动用透支额度，之后由后续入账资金冲平。该顺序请参阅
[余额与账户历史](/docs/zh/support/balance-and-account-history-faq)。

需要关注的数字是 `availableOverdraftLimit`，而不是 `overdraftLimit`：额度是会被消耗的，
所以一个很大的配置额度并不能说明当前还剩多少空间。透支额度属于您的账户设置的一部分，不是自助字段——如需了解请联系支持团队。

## 为什么一次提现申请产生了两笔付款？

因为资金来自两个子账户。这只会发生在您的结算账户是**合并**（`REGULATED_CORPORATE`）类型，且单个子账户不足以覆盖金额的情况下：

| 情形 | 从您账户划出的款项 |
| - | - |
| 受监管侧足以覆盖全额 | **一笔**付款，全部来自受监管侧 |
| 受监管侧没有余额 | **一笔**付款，全部来自企业侧 |
| 任何一侧都无法单独覆盖 | **两笔**付款——先把受监管侧划空，剩余部分由企业侧补足 |

始终先划扣受监管侧。每一段都会成为独立的对外付款、各有自己的金额，所以您的银行流水可能对一次提现申请显示两笔入账，
而且它们未必同时到达。

**提现手续费只收一次，不会收两次。** 提现被拆分时，全部手续费落在金额较大的那一段上，另一段完全不带手续费。
因此不要指望拆分提现的每一段都能独立轧平：一段看起来会少了全额手续费，另一段看起来刚好。请先把两段加起来，再与您申请的金额比对。

## 余额 API 也会显示子账户吗？

不会——而这正是造成混淆的差异所在。`/api/v1/account/balance/inquiry` 在 `accounts[]` 中每个币种返回一条：

| 字段 | 含义 |
| - | - |
| `accountNo` | 账号，全局唯一 |
| `currency` | 该条目的结算币种 |
| `totalBalance` | 持有的总余额 |
| `frozenBalance` | 因拒付活动被冻结的金额 |
| `reserveBalance` | 保证金账户余额；保证金不足时可以为负 |
| `availableBalance` | 您实际可提现的金额 |

`availableBalance` 是推算出来的，不是存储的：

```
availableBalance = totalBalance − frozenBalance − (reserveBalance < 0 ? |reserveBalance| : 0)
```

负的 `reserveBalance` 表示保证金缺口，其绝对值会从您的可提现金额中扣留，直到保证金重新补足。
零或正的 `reserveBalance` 永远不会减少 `availableBalance`。

请求中省略 `currency`，即可一次调用获取所有结算币种。

所以：API 视图按币种，Portal 视图可以按子账户。如果 API 显示一个账号而 Portal 显示两个，两者都没有错——请按币种总额对账，而不是按账号。

## 账户历史正确的业务类型有哪些？

**六种**，这就是 Portal 提供的筛选列表：

| `businessType` | 该行记录的内容 |
| - | - |
| `SETTLEMENT` | 一笔结算入账 |
| `WITHDRAWAL` | 一笔提现出账 |
| `ADJUSTMENT` | 一笔人工调整 |
| `RESERVE_WITHHOLDING` | 扣留进保证金的金额 |
| `RESERVE_RELEASING` | 一笔保证金扣留被释放 |
| `RESERVE_ADJUSTMENT` | 从您的结算账户补足被动用的保证金 |

注意拼写：是 `WITHDRAWAL`，不是 `WITHDRAW`。

后三种很重要，因为保证金变动就是通过它们体现在您的账目里。如果您一直在账户历史里按结算或调整类型筛选、想找保证金活动，
请改为按 `RESERVE_*` 值筛选。较早的记录仍可能带有已不再产生的类型（换汇提前到提现之前执行以前的外汇 `Conversion` 行），
所以当您要核对每一笔变动时，**先不加筛选查询**，再逐步缩小范围。

## 账户历史覆盖我的保证金账户吗，还是只有结算账户？

取决于您在哪个界面查看：

| 界面 | 范围 |
| - | - |
| `/api/v1/account/history/inquiry` | **两者都有。** 每次 API 查询都同时跨结算账户和保证金账户；省略 `accountType` 则两者都返回 |
| Portal **Account → Balance → Balance History** | **结算账户**——该页面查询的是这个账户 |
| Portal **Reserve Account** 模块 | **保证金账户**——扣留、释放和调整，各有自己的历史页签 |

账户类型值为：

| `accountType` | 账户 |
| - | - |
| `MERCHANT_SETTLEMENT` | 您的结算账户 |
| `MERCHANT_RESERVE` | 您的保证金账户 |

`/api/v1/account/history/inquiry` 在请求和每条返回行上都接受这两个值，所以在混合结果集中，
`accountType` 就是您区分保证金变动和结算变动的依据。记录还带有 `accountNo`、`businessId`（引起该变动的交易）、
`amount`、`currency`、`accountDirection`（`DEBIT` / `CREDIT`）、`newBalance`（变动后即时余额）和 `transactionTime`。

如果您的结算账户是拆分的，还可以在 Portal 视图中按子账户进一步筛选，即按 `REGULATED` 或 `CORPORATE` 筛选。
合并类型不是筛选选项——合并账户就是一个账户，没有可以缩小的范围。

## 我可以查询多长的日期范围，可以导出什么？

| 操作 | 限制 |
| - | - |
| `/api/v1/account/history/inquiry` | 每次请求最多 **180 天**；`startTime` 和 `endTime` 均为必填 |
| Portal 账户历史查询 | 起止均为必填；服务端无最大窗口限制 |
| Portal 账户历史导出 | 最多 **31 天**——范围更大会在生成文件之前被拒绝 |

导出是更严格的约束，所以请按月分段规划对账，而不是查询一个很宽的范围再尝试导出。导出的是一个 CSV 文件，命名为
`account_history_{merchant id}_{from}_{to}.csv`。

## 退款的处理手续费什么时候会退还给我？

退款是否退还原支付的部分处理手续费是一项**合同设置**，有两种状态：

| 退款手续费策略 | 行为 |
| - | - |
| `NO` | 退款时不退还任何手续费。这是常见的设置。 |
| `REFUND_BY_RATIO` | 按退款金额比例退还手续费。 |

在 `REFUND_BY_RATIO` 下，退还的手续费按退款金额与原订单金额的比例计算，并按您的结算币种小数精度**向下取整**。
由于每次部分退款都是独立地按原订单计算且总是向下取整，一系列部分退款退还的手续费总额可能略少于一次全额退款——这个差额是取整造成的，不是漏了记录。

在您的结算报表中，退还的手续费会减少该周期的手续费总额；数字落在哪里请参阅
[结算报表](/docs/zh/support/settlement-reports-faq)。

## 我的退款手续费完全没有退还，是什么在阻止？

系统强制执行一条硬规则：**支付的手续费币种和退款的手续费币种必须一致。** 不一致时，退款不会被悄悄地按零手续费退还处理——
该批次的结算运行会失败并进入排查，所以在问题解决之前，该变动根本不会出现在您的对账单中。
同一检查还要求原支付的结算币种与其所在清算批次的结算币种一致。

如果您预期有手续费退还的某笔退款完全没有出现在结算中，而不是以零手续费退还的形式出现，就应该向支持团队询问这项检查——请提供退款 id 和原订单 id。

除此之外，如果策略是 `NO`，手续费退还就根本不适用。

## 我的拒付手续费一定是美元吗？

不是。拒付手续费币种来自**您的**商户配置，并在每个案件上以 `feeCurrency` 与 `feeAmount` 一并返回。它不固定为 USD，也不必与您的结算币种一致。

当手续费币种与您的结算币种不同时，手续费会在**结算时、按该次结算自身的汇率**换算成结算币种——而不是案件建立时锁定的汇率。
两者一致时不发生换算。拒付本金和拒付手续费按各自独立的汇率基准换算，所以在跨币种案件上，金额和手续费看起来不会像使用了同一个汇率。

结果是：对账单可能合理地显示一笔您没预料到的币种的拒付手续费，旁边附有换算后的数字。产生的结算行如何标注，请参阅
[拒付字段参考](/docs/zh/support/chargeback-field-reference)。


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