Glossary

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

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 carry exactly six decimal places and 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 bank rails (PesaLink, RTGS, EFT) and, for payments in, over M-PESA. USDT travels over Tron. 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 two ways your payer can fund a buy order. It cannot carry a payment reference, so the account number does the identifying.

Rate

How many shillings one USDT is worth on a given quote. It is locked when the quote is issued and spent when the order is created.

Payout account

A Kenyan bank account, registered with us in advance, that a sell order can pay shillings into. You choose which one when you create the order. A payout account cannot be an M-PESA wallet.

Collection account

The account, issued to you by us, that your payers send shillings to when funding a buy order. The payment details come back with every order and are also available on request.

Deposit address

Your Tron address at OnLink, where you send USDT to fund a sell order. It is the same address for every one of your orders, which is why the transaction hash matters.

Withdrawal address

A Tron address of yours, registered and then confirmed through the API, that a buy order can send USDT to. Confirmation exists so a mistyped address is caught before any value moves.

Orders and their life

Quote

A locked exchange rate with the exact amounts on both sides, 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. It is created first and completed later. See How it works.

Funding window

The time you have to fund an order after creating it. An order that is not funded before its deadline expires; an order that has been funded never does. The deadline is returned with every order.

Funds confirmed

The moment your payment or deposit has arrived and been matched to your order. We send a webhook when it happens. It is the point at which you can tell your customer the money was received.

Settlement

The completion of an order: the shillings have been paid to your payout account, or the USDT has been sent to your withdrawal address. Settlement happens after the order is created, on its own timeline. See Asynchronous settlement.

Terminal state

A state an order cannot leave. There are three: settled (the value moved), rejected (we could not complete it, and your funds are with us) and expired (it was never funded). Each sends a webhook.

Expired

The terminal state of an order that was not funded within its window. Nothing moved, nothing is owed. Take a new quote if you still want to convert.

Rejected

The terminal state of an order we could not complete. Your funds have arrived and the payout will not happen; resolving it is a conversation with us. See Status and support.

Attribution

Working out which order a payment or deposit belongs to. On a sell order the transaction hash does it; on a buy order the payment reference or your collection account does. See References and attribution.

Transaction hash

The unique identifier of a transfer on the Tron network, produced when you send USDT. You attach it to your sell order so we can tie your deposit to it.

Partner reference

An identifier you choose and attach to every order — your own order number, for example. It is how you match our orders to your records, and it is what makes retrying safe: sending the same reference twice returns the same order.

Payment reference

An identifier we issue with each buy order for your payer to put on a bank transfer. It lets us match the payment to the order exactly. M-PESA cannot carry it, so there the collection account does the matching.

Integration

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 something about an order changes: your funds are confirmed, or the order reaches a terminal state. It is how your product finds out an order 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, and handling a webhook is idempotent on its delivery id — so retries and duplicate deliveries are safe. See Idempotency and references.

Request id

A number 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.