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.

Everything built on this API is money arriving in Kenya, money leaving, or a conversion between shillings and USDT — wrapped in a product of your own. This page shows how different kinds of business put the pieces together, and where the line between your product and our service falls in each case.

The building blocks

Block	What it does	Use it when…
KES balance	The shillings you hold with us, topped up by M-PESA or bank transfer, read at any time.	Always — every payout and every buy is paid from it.
M-PESA prompt	Raises a payment prompt on a payer's phone, paying into your KES balance.	You want to ask a payer to pay, rather than wait for them.
Transfer	Pays shillings from your balance to M-PESA or a bank account, after a one-time code.	You are paying someone — an individual or a business — in Kenya.
Batch of transfers	Many transfers under one instruction and one confirmation.	You are running a payroll or a supplier payment run.
Quote	Locks an exchange rate and the fee for a short window, with the exact amounts on both sides.	You are about to show a customer a price, or commit to one yourself.
Buy order	Converts shillings from your balance into USDT.	Shillings are coming in and need to leave as USDT.
Sell order	Converts USDT from your balance into shillings paid to your own OnLink KES account.	Value is leaving USDT and needs to arrive in Kenya as shillings.
USDT send	Sends USDT from your balance to a withdrawal address, after a one-time code.	USDT needs to leave you for a wallet you control or pay.
Withdrawal addresses	Your registered and confirmed USDT addresses a USDT send can go to.	You want to add or check where USDT can land.
Payout accounts	The list of your own OnLink KES accounts a sell order can pay to.	You want to know, or choose, where shillings land.
Collections	A reference and US deposit details for a contributor paying in US dollars.	You collect in the US.
Conversion	Turns the US dollars in your USD account into shillings in your KES account.	Dollars you collected need to be paid out in Kenya.
Webhooks	Signed messages to your system when money lands, and when anything you started finishes.	Always. They are how your product learns something finished.

Remittances into Kenya

The picture. Money is sent from abroad and needs to reach someone in Kenya as shillings. Your operation receives the value as USDT.

What you build. Your app takes the sender's money and your treasury holds USDT with us. When a batch is ready, you sell USDT to OnLink, and then pay each recipient from your KES balance — one transfer each, or one batch — to their M-PESA or bank account.

What is yours. The sender and the recipient are your customers. You verify them, you decide who may send, and you confirm every payout with the one-time code sent to the person you nominated, or to your webhook if your account uses webhook delivery. OnLink can also waive confirmation for your account. In production it then applies only when you call with an API key that has an IP allowlist.

Which flows. Sell USDT, receive KES, then Send a batch of transfers.

Exchanges and wallet apps

The picture. Your customers hold balances with you and want a way in and out of shillings.

What you build. A customer who wants to buy USDT pays shillings into your KES balance, and you can raise an M-PESA prompt on their phone for exactly that. When the credit lands, you buy the USDT from your balance and credit their account in your own ledger. A customer who wants to cash out is the mirror image: you sell USDT and pay them from your KES balance.

What is yours. Onboarding and verifying every customer, running your own ledger of balances, and knowing which of your customers each credit came from.

Which flows. Receive money in Kenya and Buy USDT with KES for the way in; Sell USDT, receive KES and Send money from your KES account for the way out.

Treasury: revenue in one currency, costs in the other

The picture. A company earns in shillings and has USDT obligations, or holds USDT and has payroll, rent and suppliers to pay in Kenya.

What you build. Very little. Your finance system creates orders when it needs to rebalance: sell USDT when shillings are due, buy USDT when shillings are piling up. Each order carries your own reference, so your accounting matches it without a manual reconciliation.

What is yours. Deciding when and how much to convert, and the onward payments.

Which flows. Both conversions, depending on which way the balance needs to move.

Paying suppliers and contractors in Kenya

The picture. A platform owes shillings to people and businesses in Kenya, and holds either shillings or USDT to pay them from.

What you build. Before a payment run, top up your KES balance, or sell the USDT you need. Then send one batch of transfers, each carrying a partnerReference of your own, so every payment lines up with an invoice in your records.

What is yours. Knowing who you are paying and why, and confirming each payment run.

Which flows. Send a batch of transfers, with Sell USDT, receive KES if you start from USDT.

Collecting from many payers

The picture. Many payers — members, customers, contributors — each send money towards one purpose, and you need to know who paid.

What you build, in shillings. Payers top up your KES balance, and each credit reaches you as a credit.received webhook carrying the payer's own rail reference, the amount and the time. That is what you reconcile against your roll of who owes what. Where you want a payment you can place with certainty, raise an M-PESA prompt on the payer's phone yourself, so you started it.

What you build, in US dollars. Open a collection for each payment you expect, and hand the contributor its deposit details — including the deposit message they must quote. Each collection takes one deposit, which is paid into your USD account, net of fee, and a collection.received webhook tells you when it has landed. Convert those dollars to shillings in your KES account with Convert USD to KES, and pay them out from there; see Collect in the US, pay out in Kenya.

What is yours. The payer relationship, and the roll of who paid what.

Which guides. Receive money in Kenya Open a collection and Convert USD to KES.

What every case has in common

Money lands in places you registered or approved. Sell proceeds land in your own OnLink KES account, and USDT addresses are registered and confirmed through the API. Every transfer and USDT send waits for a code sent to someone you nominated, or to your webhook if your account uses webhook delivery. OnLink can also waive confirmation for your account. In production it then applies only when you call with an API key that has an IP allowlist.
You hold the customer relationship. We move value for your business. Your users never see or deal with OnLink, and verifying them is your job.
Nothing is finished until we say so. Everything settles after it is created. Design your product to show "in progress" and to react to our webhook, not to assume completion.
Your reference is the thread. Put your own identifier on every order, transfer and send, and reconciliation becomes a lookup rather than a search.

How it works if you skipped ahead.
Who does what for the full division of obligations.
Get started to hand the integration to your engineers.