Building Payments on Half an API, Literally.

When we started building payments into Agabb, we assumed the hardest part would be integration. We were wrong. The real challenge was scope.

In Somaliland, there are only two mobile money services that people actually use. They work well for what they were designed for. Person-to-person transfers. Manual payments. Everyday use. They power most of the economy.

But when you step into building software on top of them, the limitations become very clear.

Both services offer payment APIs, but only in one direction. You can bill a customer. You can collect money programmatically. That is where it stops.

Once money is collected, it settles into a merchant account. From there, everything becomes manual again. If you want to pay a vendor, an employee, or an expense, you have to pull out your phone and initiate the transfer yourself. There is no way to move money out programmatically from the same account that received it.

That missing half changes everything.

A checkout is not just about collecting money. It is about completing a transaction. Money moves from a customer, through a system, and ends up where it belongs. That requires a two-way flow. What exists today is one-sided.

Because of that, we can only support a narrow set of use cases. Subscriptions work, because they stop at collection. But real checkout does not. We cannot settle payments directly into a retailer’s account within a single flow. We cannot pay expenses from the system. We cannot schedule recurring payments like rent, salaries, internet, or utilities. We cannot pay vendors while sourcing or negotiating prices.

All of these features sit on our roadmap, ready to be built. And all of them are blocked by the same constraint.

To do any of this properly, money has to move end to end. A customer pays. Funds settle. Then those funds can be distributed automatically, based on context and rules. That is what turns payments into infrastructure rather than isolated events.

I do not necessarily blame the providers. They have built what users asked for. If customers only need manual transfers, there is no immediate pressure to expose more. But the absence of this capability shapes everything that can be built on top.

Our product roadmap is shaped less by what we want to build and more by what the underlying infrastructure allows. We want to move faster. We want to build deeper. But building in Somaliland means working within real constraints.

And maybe that is part of the point.

What is the fun in having everything already figured out. Some things have to be broken for it to be worthwhile.