Frequently asked questions

Short answers, each with a link to the page that has the long one. If your question is not here, email info@onlink.africa.

The basics

What does the API do, in one sentence?

It moves money into and out of Kenya for your business. Shillings arrive in a balance you hold with us and leave it to M-PESA or a bank account, and you can convert between shillings and USDT at a quoted rate. You can also collect US dollars in the US, then convert them to shillings or pay them out as dollars. What is the OnLink API? has the longer version.

Do I need to understand blockchains to use it?

No. If you only move shillings, there is no blockchain anywhere in your integration. If you use the USDT product, your USDT is held with us as a balance, and you only need a wallet of your own if you want USDT sent out to it. Everything else — rates, crediting payments, paying out — is behind the API. The Glossary covers every term you will meet.

Which currencies and networks are supported?

Kenyan shillings, and USDT on the Tron network — no other token and no other network. USDT sent on a different network cannot be credited or returned, so this is worth stating to anyone who touches a wallet. Separately, the collections product accepts US dollars from contributors in the US, by ACH, FedNow or wire, into a USD account. From there the dollars can be converted to shillings (US dollars to shillings is the only pair), or paid out as dollars to a USD bank account by RTGS, EFT or SWIFT. See Rails.

Is this for individuals?

No. The API is for businesses that hold a relationship with the people whose money is moving. OnLink does not offer a self-serve trade or a stablecoin wallet to individuals through it.

Money in, money out

Where does the money go?

Where you tell it to, with two safeguards. The proceeds of a sell order are paid into your own OnLink KES account. A USDT send can only go to an address you registered and confirmed through the API. And every transfer or USDT send waits for a one-time code sent to someone you nominated, so whoever holds your API credentials cannot move money out on their own. There are two exceptions.

The first is an account that receives confirmation codes by webhook. There, one backend holding both your API secret and your webhook endpoint holds both factors. See the Security section of Auto-confirm instructions.

The second is an account OnLink has enabled confirmation waiving for. There, your API key and secret, used from an IP address on that key's allowlist, can move money with no code at all in production, up to your caps. See When confirmation is waived.

Can my customers pay with M-PESA?

Yes. Your payer sends shillings into your KES balance, by M-PESA Pay Bill or by bank transfer — or you raise an M-PESA prompt on their phone yourself. Each credit reaches you as a webhook carrying the payer's own rail reference. See Receive money in Kenya.

Can you pay my customers out over M-PESA?

Yes. A transfer pays shillings from your KES balance to an M-PESA number, or to a bank account by PesaLink, RTGS, EFT or SWIFT, and a batch pays many recipients at once. See Send money from your KES account. The proceeds of a sell order are different: they settle to your own OnLink KES account, and you pay onward from it with a transfer. On the collections product you can also pay US dollars out of your USD account, to a USD bank account by RTGS, EFT or SWIFT; see Paying out USD.

How long does a conversion take?

It is not immediate. An order is created first and settles later, and you find out through a webhook rather than by waiting on the request. Each quote comes with a rough estimate you can show your customer; treat it as a guide for expectations, not a deadline to build around. How it works explains the sequence. A conversion of US dollars to shillings behaves the same way: it is accepted first, and a webhook tells you when it has settled or failed.

What if the exchange rate moves?

The rate on your quote is held until the quote expires, and the order that uses it executes at that rate. If the quote expires before you act, you take a new one and see the new amounts. Nothing is ever re-priced without you seeing it. See Quotes.

A conversion of US dollars to shillings works differently. Its quote is indicative and holds nothing: the rate is fixed when the conversion executes, and you read it back afterwards. If the rate has moved too far since you created the conversion, it fails and your dollars are returned, rather than converting at a rate you did not see. See Convert USD to KES.

Is there a minimum or a maximum?

Orders and transfers have no minimum beyond an amount above zero; a USDT send has a small minimum. There are two ceilings — a per-instruction maximum, and one rolling 24-hour maximum that your orders, transfers and USDT sends share — and both are set for your account during onboarding rather than published here. A conversion of US dollars to shillings counts against neither: it has a USD 1.00 minimum and one maximum per conversion, the same for every partner. See Caps and limits.

What does it cost?

Our fee on a conversion is a separate, named amount: every quote and order carries a fee object and the total that actually moves, so you can show your customer both before they commit. The terms themselves — a percentage, a flat amount and an optional cap — are part of your partner agreement; ask us. Fees explains how the fee is applied and rounded. A conversion of US dollars to shillings carries no fee line: what it costs you is in its rate, which you can see on the quote and on the conversion itself.

What happens if something goes wrong?

An order whose funds cannot be taken is refused when you create it. An order we cannot complete afterwards is rejected, and a payout the rail refuses fails — in which case the money never left. None of these is silent: each ends in a status you can read and a webhook. If funds left your balance for something that ended rejected, resolving it is a conversation with us, with the id and your reference to hand. A conversion that fails pays no shillings, and it is reported failed only once any dollars it took are back in your USD account.

Responsibilities and compliance

Do my customers need an OnLink account?

No. Your customers deal with you and never with OnLink. We do not see them.

Who verifies my customers?

You do. Identifying and verifying your users is your obligation, under your own registrations, and so is deciding who may transact on your platform. We screen each movement of value and its counterparties. Who does what draws the line in full.

Will you ask me about a transaction?

Sometimes, yes. If we need information about a movement, we ask you, because you are the party who has it. Being able to reach the customer behind an order and answer promptly is part of the integration.

Getting started

Can we try it before committing?

Yes. Everything starts in sandbox, a complete copy of the service where no real value moves. Ask for access and your engineers can integrate end to end, including receiving real signed webhooks. See Get started.

Is it live in production?

Production access is enabled per partner once an integration has been built and certified in sandbox. Nothing in the code changes at that point except the address it talks to and the credentials it uses.

Can we call it from a mobile app or a website directly?

No. It is a server-to-server API. Every request is signed with a secret that must never be shipped inside an app or a web page, so your own backend makes the calls.

How is it secured?

Every request is signed, so a captured request cannot be replayed. Quotes are single-use. Creating an order twice with the same reference cannot produce two orders. Every transfer and USDT send needs a one-time code that goes to a person, not to your integration — unless you ask us to push codes to your signed webhook, as described in Auto-confirm instructions. We can also waive the code for your account. In production that applies only when you call with an API key that has an IP allowlist; see When confirmation is waived. See Authentication and API credentials.

What do our engineers need to know first?

Three things: settlement is asynchronous, every amount is text with fixed decimal places, and every request is signed. Get started takes them from credentials to a first signed call and a complete order.

How do we get help?

Email info@onlink.africa. Check onlink.africa/status first, and include the requestId from any error response. Status and support lists what to include.