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… |
|---|---|---|
| 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. |
| Collection account | The account we issue you that a payer funds a buy order into, over a Kenyan rail. | Shillings are arriving from payers rather than from your own wallet. |
| 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.
Collecting from many payers
The picture. Many payers — members, customers, contributors — each send shillings towards one purpose, and you need to know who paid.
What you build. Every shilling that arrives is the funding leg of a buy order, so each expected payment gets an order of its own. Your app shows that payer the account we issue you, and what you receive is USDT at your registered address. On a bank transfer the reference we issue travels with the payment and attributes it exactly. On M-PESA nothing travels, and two open orders for the same amount in the same window are held rather than guessed. So a round-sum collection over M-PESA needs distinct amounts, or a bank transfer.
What is yours. The payer relationship, and the roll of who paid what. The attribution asymmetry is the design constraint here, and it is worth knowing before you build.
Which guide. Receive money in Kenya, then Buy USDT with 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.