Skip to main content
Balances & account history explains what each balance means and why your withdrawable amount can be lower than your settlement balance. This page covers the shape of the accounts underneath: why a single settlement currency can present more than one account number, why one withdrawal instruction can arrive as two payments, and which filter values Account History actually accepts. For the withdrawal APIs themselves see Withdrawals & balance API.

​
Why does one settlement currency show two account numbers in the Portal?

Because a settlement account can be split into two sub-accounts, and where yours is, the Portal shows you both. Each account carries an accountSubType: Which of the three applies to you follows from how your account was set up; it is not a setting you change. Two consequences worth internalising:
  • With REGULATED_CORPORATE you see one account number per currency and everything behaves as a single pot.
  • With separate REGULATED and CORPORATE accounts you see two rows for the same currency, each with its own account number and its own available balance. Your total position in that currency is the sum of the two — no single row shows it.
The account view returns these as a subAccounts list hanging off the currency-level account, so a row with a populated subAccounts list is a parent and its balance detail is in the children.

​
What are overdraftLimit and availableOverdraftLimit?

Each account can carry an overdraft allowance, reported as two fields: These explain how a balance can be negative without anything having gone wrong: chargebacks and chargeback fees are attempted against your balances in a fixed order and, at the end of that order, may draw on the overdraft, which is then cleared by later incoming funds. See Balances & account history for that ordering. availableOverdraftLimit is the number to watch, not overdraftLimit: the allowance is consumed, so a large configured limit tells you nothing about current headroom. An overdraft allowance is part of your account setup, not a self-service field — contact support to discuss it.

​
Why did one withdrawal request produce two payments?

Because the funds came from both sub-accounts. This happens only where your settlement account is the combined (REGULATED_CORPORATE) type, and only where one sub-account alone could not cover the amount: The regulated side is always drawn down first. Each leg becomes its own outward payment with its own amount, so your bank statement can show two credits for one withdrawal request, and they may not arrive at the same moment. The withdrawal fee is charged once, not twice. Where the withdrawal splits, the whole fee sits on the larger of the two legs and the other leg carries no fee at all. So do not reconcile a split withdrawal by expecting each leg to net out independently: one leg will look short by the full fee, the other will look exact. Add the legs together before comparing against what you asked for.

​
Does the balance API show sub-accounts too?

No — and this is the difference that causes the confusion. /api/v1/account/balance/inquiry returns one entry per currency in accounts[]: availableBalance is derived, not stored:
A negative reserveBalance is a reserve shortfall, and its absolute value is held back from what you can withdraw until the reserve is whole again. A zero or positive reserveBalance never reduces availableBalance. Omit currency on the request to get every settlement currency in one call. So: the API view is per currency, the Portal view can be per sub-account. If the API shows one account number where the Portal shows two, neither is wrong — reconcile on the currency total, not on account numbers.

​
What are the correct Account History business types?

Six, and this is the filter list the Portal offers: Note the spelling: WITHDRAWAL, not WITHDRAW. The last three matter because they are how reserve movements appear in your ledger. If you have been filtering Account History expecting to find reserve activity under a settlement or adjustment type, filter on the RESERVE_* values instead. Older rows can still carry a type that is no longer produced (an FX Conversion row from before conversion moved ahead of withdrawal), so query unfiltered first when you are trying to account for every movement, then narrow down.

​
Does Account History cover my reserve account, or only the settlement account?

It depends on which surface you are reading: The account type values are: The same two values are accepted by /api/v1/account/history/inquiry on both the request and each returned row, so accountType is how you tell a reserve movement from a settlement movement in a mixed result set. Rows also carry accountNo, businessId (the transaction that caused the movement), amount, currency, accountDirection (DEBIT / CREDIT), newBalance (the balance immediately after the movement) and transactionTime. Where your settlement account is split, you can additionally narrow the Portal view by sub-account, filtering on REGULATED or CORPORATE. The combined type is not a filter option — a combined account is one account, so there is nothing to narrow.

​
What date range can I query, and what can I export?

The export is the tighter constraint, so plan reconciliation in monthly slices rather than querying a wide range and then trying to export it. The export is a CSV named account_history_{merchant id}_{from}_{to}.csv.

​
When is a refund’s processing fee returned to me?

Whether a refund returns any of the original payment’s processing fee is a contract setting, with two states: Under REFUND_BY_RATIO the returned fee is pro-rata on the refunded amount against the original order amount, and it is rounded down to your settlement currency’s decimal precision. Because every partial refund is computed against the original order independently and always rounds down, a series of partial refunds can return slightly less in total than a single full refund would have — that difference is the rounding, not a missing entry. In your settlement reports the returned fee reduces the fee total for that period; see Settlement reports for where the figure lands.

​
My refund fee was not returned at all. What blocks it?

One hard rule is enforced: the payment’s fee currency and the refund’s fee currency must match. Where they do not, the refund is not quietly given a zero fee return — the settlement run for that batch fails and is investigated, so the movement will not appear in your statement at all until it is resolved. The same check requires the original payment’s settlement currency to match the settlement currency of the batch it is being cleared in. If a refund you expected a fee return on is missing from a settlement entirely, rather than present with a zero fee return, this is the check to ask support about — quote the refund id and the original order id. Beyond that, the fee return simply does not apply where the strategy is NO.

​
Is my chargeback fee always in USD?

No. The chargeback fee currency comes from your merchant configuration, and it is returned on each case as feeCurrency next to feeAmount. It is not fixed to USD and it does not have to match your settlement currency. Where the fee currency differs from your settlement currency, the fee is converted into the settlement currency at settlement time, using that settlement’s own rate — not a rate captured when the case opened. Where the two match, no conversion happens. The chargeback principal and the chargeback fee are converted on separate rate bases, so on a cross-currency case the amount and the fee will not appear to have used one single rate. The result: a statement can legitimately show a chargeback fee in a currency you did not expect, with a converted figure next to it. For how the resulting settlement lines are labelled, see Chargeback field reference.