Glossary
Every term used in these docs, defined once in plain language, from stablecoin to terminal state.
Terms are grouped by where you meet them. Each heading is a link you can share:
/docs/overview/glossary#webhook, for example.
Money and rails
KES
Kenyan shillings, the currency of Kenya. On this API, shilling amounts always
carry exactly two decimal places and are written as text, for example
"32025.00".
USD
US dollars. On this API they appear on the collections product — in
collections, in the USD balance, in conversions and in USD transfers — as text
with two decimal places, for example "100.00", or, in fee terms, as whole
cents.
Stablecoin
A digital token designed to hold a steady value against a national currency, usually the US dollar. It moves over a blockchain network rather than through banks, which is what lets value cross borders at any hour.
USDT
The stablecoin this API deals in. One USDT is intended to track one US dollar.
Amounts are written as text, for example "250.000000".
Tron (TRC-20)
The blockchain network our USDT moves over. TRC-20 is the technical standard for tokens on Tron. It is the only network this API supports: USDT sent on any other network cannot be credited or returned. See USDT on Tron.
Rail
The route money travels on. Shillings reach us or leave us over M-PESA and the bank rails (PesaLink, RTGS, EFT, and SWIFT for payouts). USDT travels over Tron. US dollars for collections arrive by ACH, FedNow or wire, and a USD transfer leaves by RTGS, EFT or SWIFT. See Rails.
M-PESA paybill
A way for a payer in Kenya to send shillings to a business from their phone, using a business number and an account number. On this API it is one of the ways a payer tops up your KES balance. It carries no reference of yours, so a payment is identified afterwards by the payer's own M-PESA receipt code.
M-PESA prompt
A payment request we raise on a payer's phone at your instruction, which they approve with their own PIN. The money lands in your KES balance.
Balances and accounts
KES balance
The shillings you hold with us, in a KES account issued to your partner account. Payers top it up; transfers and buy orders are paid from it. See Balances.
USD balance
The US dollars you hold with us on the collections product, in a USD account issued to your partner account. Collections are paid into it, net of fee; conversions and USD transfers are paid from it. See Balances.
USDT balance
The USDT you hold with us. On a managed-balance account, a buy order credits it and sell orders and USDT sends are paid from it; an account set up with its own wallet receives buys on-chain and sells from that wallet. You can read it from the API at any time. See Balances.
Holding wallet
The wallet that holds your USDT. On a managed-balance account it is your own deposit address with us, and USDT sent to it is credited to your USDT balance. On an account set up with its own wallet it is that wallet: your sells and sends draw from it. The API tells you which you have, and returns the address in full. It is not one of your withdrawal addresses, which are external destinations you register and send USDT to. See Where your USDT is held.
Deposit address
The Tron address you send USDT to: your holding wallet's address, as deposit instructions give it. Where we hold your USDT, USDT sent to it tops up your USDT balance, and each arrival is announced by a webhook. Where you hold your own wallet, it is that wallet, and USDT sent to it simply arrives there.
Payout account
Your own OnLink KES account, which a sell order pays shillings into. The API lists it, and you name it by its id when you create the order. You can pay the proceeds onward from it with a transfer.
Withdrawal address
A Tron address of yours, registered and then confirmed through the API, that a USDT send can go to. Confirmation exists so a mistyped address is caught before any value moves.
Confirmation contact
The person you nominated to receive one-time codes. Every transfer and every USDT send waits until the code we sent them is submitted back to us. If we have switched your account to webhook delivery, the code goes to your webhook instead, and if we have enabled confirmation waiving for it, then in production a key with an IP allowlist is not asked for a code. See Auto-confirming instructions.
Orders and their life
Quote
A locked exchange rate with the exact amounts on both sides and our fee, valid for a short window. A quote is used once: the order that uses it spends it. See Quotes.
Order
A single conversion: sell USDT for shillings, or buy USDT with shillings, at the rate a quote locked, paid for from the balance it starts in. It is created first and completed later. See How it works.
Fee
Our charge on an order, stated as its own amount on every quote and order, beside the total that actually moves. See Fees.
Settlement
The completion of something you started: an order's other side delivered, or a transfer or send paid out on its rail. Settlement happens after the request, on its own timeline. See Asynchronous settlement.
Terminal state
A state that cannot change again. An order ends settled, rejected or expired; a transfer or a USDT send ends settled or failed, or expired if nobody confirmed it; a conversion ends settled or failed. Each is announced by a webhook.
Expired
The terminal state of an order that could not be funded within its window, or of a confirmation nobody submitted in time. Nothing moved.
Rejected
The terminal state of an order we could not complete. If funds left your
balance for it, resolving it is a conversation with us: a buy's
kesDebit.status reads reversal_pending while the KES is owed to you. See
Status and support.
Payouts
Transfer
An instruction to pay shillings from your KES balance to an M-PESA number or a bank account, or, on the collections product, US dollars from your USD balance to a USD bank account by RTGS, EFT or SWIFT. It moves nothing until it is confirmed. See Send money from your KES account.
Batch
Many transfers under one instruction and one confirmation, each settling on its own. See Send a batch of transfers.
USDT send
An instruction to send USDT from your balance to one of your withdrawal addresses. Like a transfer, it waits for a confirmation. See Send USDT from your wallet.
Confirmation
The one-time code step between an instruction and the money moving. The code goes to your confirmation contact, or to your webhook on an account switched to webhook delivery, and your integration sends it back to us before anything moves. An account with confirmation waiving enabled skips the step, in production, for an API key that has an IP allowlist.
Failed
The terminal state of a transfer or a USDT send that did not go out. The money never left.
Collections
Collection
A reference and a set of US deposit details for one deposit. The first deposit made to it is paid into your USD account, net of fee; open a new collection for each payment you expect. See Open a collection.
Deposit message
A code we mint for a collection that shares a deposit account with others. The contributor must quote it in their transfer so the deposit can be attributed to the collection.
Conversion
Turning US dollars in your USD account into shillings in your KES account, in one request. It needs no confirmation code, because both accounts are yours, and it locks no rate: the rate is fixed when it executes, and you read it back afterwards. It ends settled or failed, and a failed conversion returns any dollars it took. Nothing is converted unless you ask. See Convert USD to KES.
Identifying things
Partner reference
An identifier you choose and attach to an order, a transfer, a send or a conversion — your own order number, for example. It is how you match our records to yours.
Idempotency key
A value you send with a transfer, a USDT send or a conversion so that sending the same request twice creates it once. Orders are made safe to retry by their partner reference instead.
Rail reference
The identifier the payer's own rail gives a payment — an M-PESA receipt code, or a bank's reference. It arrives on the webhook for every credit to your account, and it is the one handle a payer can quote back to you.
Transaction hash
The unique identifier of a transfer on the Tron network.
Integration
Product
What your partner account is set up for: the USDT rails, or collections. Your credentials can only carry that product's scopes. See Products and scopes.
Scope
A permission a credential carries, such as transfers:write. A request needing
a scope the credential lacks is refused.
Sandbox
A complete copy of the service where no real value moves. Your engineers build and test against it first, including receiving real signed webhooks. Production access is enabled per partner once the integration is ready. See Sandbox.
Webhook
A short, signed message we send to a web address you gave us when money lands in your account or when something you started changes state. It is how your product finds out something finished. See Webhooks.
Signature
A code attached to every request you send us, and to every webhook we send you, computed from the message and a secret only the two of us know. It proves who sent the message and that nothing in it changed on the way. See Authentication.
Nonce
A value used once, sent with every request, so that a request someone captured cannot be sent again later and accepted.
Idempotency
The property that doing something twice has the same effect as doing it once. Creating an order is idempotent on your partner reference, a transfer, send or conversion on its idempotency key, and handling a webhook on its delivery id — so retries and duplicate deliveries are safe. See Idempotency and references.
Request id
A value on every error response we return. It is the one handle that finds your exact request in our logs, so quote it whenever you contact us.
OpenAPI spec
A machine-readable description of every operation on the API. Engineers import it into tools like Postman or generate client code from it. See the API reference.
Use cases
What remittance operators, exchanges, treasury teams, platforms paying people in Kenya and products collecting from many payers build on the API, and what stays with you in each case.
Frequently asked questions
The questions product, finance and compliance teams ask before an engineer is involved, answered without code.