Guides

Money in, money out, and the conversion between them: which guide you need, the four stages every order goes through, and what is true of all of them.

A guide is one job, done end to end. This section is organised the way the money moves: what arrives, what leaves, and the conversion in between.

Which way is your money moving?

flowchart LR
    accTitle: Two ways in, one conversion, two ways out
    accDescr: Money reaches you either as shillings on a Kenyan rail into your collection account, or as USDT on Tron at your deposit address. Both arrive at OnLink and are converted at the rate your quote locked. Money then leaves either as shillings to a bank account you registered, or as USDT to a wallet address you registered.
    I1[Shillings on a Kenyan rail] --> M1((OnLink))
    I2[USDT on Tron] --> M1
    M1 --> O1[Shillings to your registered bank account]
    M1 --> O2[USDT to your registered wallet address]

The same thing in order:

Money reaches you either as shillings on a Kenyan rail, paid into the collection account we issue you, or as USDT on Tron, sent to your deposit address.
It is converted at the rate the quote you took locked. One call, the same call, whichever way it arrived.
Money leaves you either as shillings into a bank account you registered with us, or as USDT to a wallet address you registered and confirmed.

Both inbound paths reach an account or address that belongs to you, and both are converted by the same call at the rate the same quote locked. Passing the value on to your own user is your part of the job — see Who does what.

Receive money in Kenya

Shillings arriving at your collection account, rail by rail — and the one rail that carries no reference at all.

Sell USDT, receive KES

Quote, create, send USDT, attach the transaction hash, receive shillings. Five steps.

Buy USDT with KES

Quote, create, have your payer pay, receive USDT. Four steps.

Every order goes through the same four stages

Whichever direction you are moving value in, an order passes through the same four stages in the same sequence.

flowchart LR
    accTitle: The four stages of every order
    accDescr: Four stages in one line, in sequence. Quote, which locks a rate. Order, which returns your instructions. Fund, when money moves in. Settle, when money moves out.
    Q[1. Quote<br/>lock a rate] --> O[2. Order<br/>get instructions] --> F[3. Fund<br/>money moves in] --> S[4. Settle<br/>money moves out]

Quote — lock a rate. You ask for a quote and receive a rate that holds for a short window. Every amount downstream comes from that rate, so you can show your user exactly what they will get before anyone commits money. A quote is spent by the order that uses it. If your user hesitates past the window, you take a new one and show the new amounts.

Order — get the instructions. You create an order against the quote. The reply tells you where the money should go: a deposit address for USDT on a sell, or the account details your payer should pay on a buy. At this point the order exists, but nothing has happened to the money yet.

Fund — money moves in. On a sell, you send the USDT and tell us which on-chain transaction was yours. On a buy, your payer sends the shillings. Once we have matched the incoming money to your order, we tell you so with a webhook. Until then, we cannot tell "not arrived" from "arrived, but we do not know which order it is for" — which is why the matching details on each guide page matter.

Settle — money moves out. We convert at the locked rate and pay out: shillings to your registered bank account, or USDT to your registered wallet address. A final webhook tells you the order settled — or, less often, that it will not.

Which guide do you need?

	Sell USDT, receive KES	Buy USDT with KES
Your user wants	Kenyan shillings, and has USDT	USDT, and has Kenyan shillings
Who sends the money in	You, from a USDT wallet	Your payer, by M-PESA or bank transfer
Where it goes in	Your OnLink deposit address	Your OnLink collection account
What comes out	Kenyan shillings	USDT on Tron
Where it lands	A bank account registered to you	A wallet address you registered and confirmed
What ties the money to the order	The transaction hash you attach after sending	The amount and the account paid on M-PESA, or the reference in a bank narration
Set up before your first order	A registered payout bank account	A registered and confirmed wallet address

What you need in place first

API credentials, carrying the scopes the guide you are following needs. See API credentials and Products and scopes.
Somewhere for the money to land. For sell orders, a bank account registered against your partner account. For buy orders, a wallet address you register and then confirm. Neither can be added in the middle of an order.
A way to hear the result. An HTTPS endpoint for webhooks. You can start by polling an order's status instead, but the webhook is the completion signal your integration should be built around.

True of every guide here

Settlement happens after the call. Creating an order does not complete it. Your product needs a state for an order that is neither done nor failed. This is the one idea that decides how you build; read Asynchronous settlement before you design anything.
The rate is locked, then spent. Nothing re-prices silently. An expired quote is refused, never quietly replaced with a fresh rate you did not see.
An order has a funding window. You have 24 hours from creation to fund an order. An order that is never funded expires; an order that has been funded does not.
Every order ends one of three ways. Settled, rejected or expired. A rejected order means your funds are with us and the order will not proceed; the resolution is a conversation with us, so have a path for it in your product. See Who does what.
The rails differ, and the differences are on their own pages. What each rail reaches, whether your reference survives it, and when it closes for the day are all on Rails.