Use cases
What remittance operators, exchanges, treasury teams and platforms paying people in Kenya build on the two conversions, and what stays with you in each case.
Everything built on this API is one of two conversions — shillings into USDT, or USDT into shillings — 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… |
|---|---|---|
| Quote | Locks an exchange rate 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. |
| Sell order | Takes your USDT and pays shillings into a bank account you registered. | Value is leaving USDT and needs to arrive in Kenya as shillings. |
| Buy order | Takes shillings into your collection account and sends USDT to an address you registered. | Shillings are coming in and need to leave as USDT. |
| Payout accounts | The list of your registered Kenyan bank accounts a sell order can pay to. | You want to know, or choose, where shillings land. |
| Withdrawal addresses | Your registered and confirmed USDT addresses a buy order can send to. | You want to add or check where USDT lands. |
| Webhooks | Signed messages to your system when funds are confirmed and when an order ends. | Always. They are how your product learns an order 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. When a batch is ready, you sell USDT to OnLink. The shillings land in your registered Kenyan bank account, and you pay each recipient from there over your own local rails.
What is yours. The sender and the recipient are your customers. You verify them, you decide who may send, and you own the last step to the recipient.
Which flow. Sell USDT, receive KES.
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 collection account, by M-PESA paybill or bank transfer, using the details we return with each order. When we confirm the payment, you credit their balance; the USDT itself lands at your registered address. A customer who wants to cash out is the mirror image: you sell USDT to us and pay the customer from the shillings that arrive in your bank account.
What is yours. Onboarding and verifying every customer, running your own ledger of balances, and paying customers out from your account.
Which flows. Buy USDT with KES for the way in, Sell USDT, receive KES 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 paying the onward bills from your bank account.
Which flows. Both, depending on which way the balance needs to move.
Paying suppliers and contractors in Kenya
The picture. A platform holds a USDT balance and owes shillings to people and businesses in Kenya.
What you build. Before a payment run, sell the USDT you need. The shillings
arrive in your registered bank account and you pay each supplier or contractor
from it, with a partnerReference per order so every conversion lines up with
a payment run in your records.
What is yours. Knowing who you are paying and why, and making the individual payments out of your account.
Which flow. Sell USDT, receive KES.
What every case has in common
- Money lands in places you registered beforehand. Bank accounts are registered with us; USDT addresses are registered and confirmed through the API. Nothing on the API can invent a new destination.
- You hold the customer relationship. We convert 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. Every order 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 and reconciliation becomes a lookup rather than a search.
Next
- 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.