Who does what

You hold the relationship with your users. We move value between USDT and KES, pay out on the Kenyan rails, receive US deposits for your collections, and screen the movement itself. The split matters because each side has obligations the other cannot discharge.

Yours

• Onboard and verify your own users. You know who they are; we do not see them. Identifying and verifying your customers is your obligation, under your own registrations.
• Decide who may transact on your platform, and monitor their behaviour over time.
• Hold the records your own regime requires, and be able to produce them.
• Keep your credentials safe. A request signed with your secret is your request.
• Tell your users what happens to their money — that settlement is not instant, and what a refusal means.

Ours

• Screen the value movement and its counterparties.
• Execute on the rails, and tell you the outcome through the order status and its webhook.
• Keep the records of what we executed.
• Refuse a movement we cannot make. A rejected order is that refusal.

Where they meet

If we need information about a movement, we ask you, because you are the party who has it. Being able to answer promptly is part of the integration, not an exception to it — build a path to reach the user behind an order.

A rejected order has no self-service reversal. If a buy was rejected after your KES was taken, its kesDebit.status reads reversal_pending while the KES is owed to you, and reversed once our refund to you completes. In either case, contact us with the orderId and partnerReference.