Settlement is how money you collect becomes money in your account. Kyshi does not pay out each transaction individually — collections are grouped into batches, converted to your settlement currency, and paid as a single transfer.

This page explains the model so your finance and engineering systems agree on what a payout represents.

Settlement data is available on your Kyshi dashboard. There is no public settlement API; reconcile from the dashboard and from the transaction records you already receive.

The Journey Of One Payment

A customer pays in their local currency.
The collection is recorded as a transaction and fees are calculated.
The net local proceeds join your balance for that currency and rail.
Once the funds are released by the underlying provider, they become eligible for settlement.
Eligible transactions are grouped into a settlement batch.
The batch is converted into your settlement currency.
The batch is paid out, and its status becomes paid.

Step 5 is where one-to-one breaks down. From that point on, your bank statement and your transaction list no longer line up row for row.

How Batches Are Grouped

A batch collects transactions that share all of the following:

your business
the region and integration the money was collected through
the settlement currency
test or live mode
the settlement date

A single batch can span multiple collection currencies settling into one settlement currency. A batch carries the list of collection currencies that fed it, so a USD batch may contain NGN and KES proceeds together.

Batches are generated automatically on a recurring schedule. A batch that is still accumulating, or awaiting payout, sits in pending.

Batch Statuses

Status	Meaning
`pending`	The batch exists and is awaiting payout.
`paid`	The batch has been paid out. It carries a payment reference and a paid-at timestamp.
`cancelled`	The batch was cancelled and will not be paid in this form.

What A Batch Records

Each batch carries both sides of the conversion, which is what makes it reconcilable.

On the local side, before conversion: gross collected, total fees, and the fee split across the Kyshi fee, processor fee, VAT, and stamp duty, plus the net local amount.

On the settlement side, after conversion: gross settlement amount, total settlement fees, and the net settlement amount — the figure that actually reaches you.

It also records the number of transactions, the period the batch covers, a summary of the FX rates applied, and, once paid, the payment reference and timestamp.

Reconciling

The rule is: reconcile at the batch level, not the transaction level.

A single line on your bank statement corresponds to one batch, which corresponds to many transactions. Systems that expect one payout per sale will never balance.

A workable process:

Match the bank credit to a batch using the payment reference and the net settlement amount.
Expand the batch to its transaction list.
Match each transaction to your own order record by reference.
Account for the difference between gross and net using the batch's fee fields.
Explain any remaining variance with the batch's FX summary.

Steps 4 and 5 are where most variance lives. A $1000 day does not settle as $1000: fees come out, and the rate applied at settlement is not necessarily the rate quoted at checkout. Both are recorded, so both are explainable — but only if you store meta.fxRate and meta.feeBreakdown on your side at the time of the sale. See Fees And Who Pays Them and FX And Rates.

Timing

Settlement timing is provider and market dependent. Kyshi does not guarantee a universal T+N settlement cycle through the API, and does not expose a fixed settlement delay as a rule across all markets and providers.

Settlement availability is based on the actual balance state of the transaction and the provider or rail used for collection. A transaction moves through states such as pending settlement, available balance, and paid out, depending on when the underlying provider confirms or releases the funds.

Because timing can vary by market, provider, rail, currency, and commercial agreement, do not hardcode a settlement delay in your integration. Build around state instead:

Instead of	Use
"Funds arrive T+2"	The transaction status
"Payout on day 3"	The available balance
A scheduled assumption	Settlement batch records
Polling on a timer	Webhook events, where available

Where a fixed settlement cycle applies contractually for a specific market or provider, this is communicated separately or documented for that market.

Test Mode

Test-mode collections are batched separately from live ones and are never paid out. This lets you exercise your reconciliation logic against realistic batch shapes without moving money. See Test Mode And Sandbox.

Balances — where funds sit before settlement
Fees And Who Pays Them — what is deducted along the way

Settlements