Sending Money to a Phone Number Over Mojaloop
In much of the world, a phone number is a bank account. Mobile money turned the MSISDN into a payable destination, and Mojaloop — the open-source interoperability engine — made those destinations reachable across providers. Sending money to a phone number over Mojaloop is one of KibiPay's core rails, and the flow is worth understanding end to end.
Start with the lookup
Before any money moves, the payer's provider has to find out who hosts the recipient's number. That is the Account Lookup Service (ALS): given an MSISDN, it returns the financial service provider that holds the account. Without this step, you would not know where to send the payment. It is proxy addressing formalised as a network primitive.
- Payer submits the recipient MSISDN.
- ALS resolves it to the recipient's provider.
- The two providers can now negotiate the transfer.
Then the quote
Mojaloop separates asking "what will this cost and what will the recipient receive?" from actually moving money. The quote step returns fees and the settlement amount so the payer sees the true cost before committing. This explicit quote is one of the things that makes Mojaloop transfers predictable rather than surprising.
| Phase | Purpose |
|---|---|
| Lookup | Find the recipient's provider |
| Quote | Agree fees and amounts |
| Transfer | Move funds with a two-phase commit |
The transfer itself
The actual transfer uses a prepare-then-fulfil pattern: the payer's side reserves funds and the recipient's side confirms with a cryptographic fulfilment. Only when both sides agree does the transfer complete. This two-phase design means a transfer either fully happens or fully does not — no half-moved money left in limbo.
Why MSISDNs make good aliases
Phone numbers are memorable, shareable, and already tied to identity through the SIM. That makes them natural payment aliases — but only once ownership is proven, which is why KibiPay gates phone aliases behind a reply-1 verification. An unverified number is a draft; a verified one is a live mobile-money destination the routing engine can select.
Fitting Mojaloop into multi-rail
When a KibiPay user pays a handle that resolves to a verified phone, Mojaloop becomes the natural rail. The sender never sees the ALS lookup or the quote mechanics — they pay a person and the mobile-money machinery runs underneath. For how the resolver decides Mojaloop is the right rail, see aliases and proxy lookups.
Where to learn more
Mojaloop is a rich system, and this is the short version. The important takeaway is that "send money to a phone number" hides a disciplined lookup-quote-transfer dance that guarantees the money is safe at every step. For the broader context of how rails differ, our primer on payment rails sets the scene.
What happens when it fails
The reassuring part of Mojaloop's design is how it handles failure. Because the transfer uses a prepare-then-fulfil pattern, a payment that does not complete leaves no half-moved money — the reserved funds are released and the payer is made whole automatically. Timeouts, an unreachable recipient provider, or a rejected fulfilment all resolve to a clean not-happened rather than a murky maybe that leaves everyone guessing. For a payer, that certainty matters more than raw speed: knowing a failed transfer definitely did not debit them is what makes a rail feel safe to use again. It also simplifies the sender's software, which can treat every transfer as strictly all-or-nothing rather than reconciling partial states. KibiPay surfaces that outcome plainly, so a user who sees a failure knows their balance is intact and can simply try again, and the routing engine can consider the next-best destination without worrying that funds are stuck somewhere in between.
A phone number in, a mobile-money credit out, and a two-phase commit making sure nothing goes missing in between — that is Mojaloop working the way it should.