As developers, we love hard problems.
So we set out to solve one that almost every African developer has faced:
“Why do I need a different integration for every mobile money provider in every country?”
Our answer was a project we called UAPL (Unified African Payment Layer) — a single API that could sit on top of providers like Campay, Flutterwave, MTN MoMo, Orange Money, Airtel Money, and others.
The goal?
Give developers a Stripe-like experience for mobile money across Africa.
Technically, we nailed it.
Legally, we walked into a wall we didn’t know existed.
This post is about the architecture we built, the performance we achieved, the failures we discovered before launch, and why we had to pivot the entire idea.
🧠 The Technical Vision
UAPL was designed as an orchestration layer with:
- Adapter pattern for each provider
- A Unified Payment Object (UPO) to normalize all APIs
- Redis-backed transaction ledger for USSD/async flows
- WebSocket events for real-time transaction updates
- Automatic provider failover (MTN → Orange if one fails)
- A clean SDK so devs never see provider differences
From a systems design perspective, it was beautiful.
You could write:
uapl.pay({
amount: 5000,
currency: "XAF",
phone: "677000000"
})
And UAPL would figure out the provider, handle retries, normalize responses, and notify your app in real time.
We load-tested the orchestration layer. It was fast. Stateless. Horizontally scalable. Provider-agnostic. Exactly what African devs need.
💥 The Discovery That Changed Everything
While preparing for real integrations with Banque des États de l'Afrique Centrale (BEAC) zone providers, we went deeper into regulatory documentation and aggregator terms.
And then we saw it.
A sentence that changes everything for fintech builders:
Any entity that routes, orchestrates, settles, or intermediates payments between merchants and licensed providers may be classified as a Payment Service Provider (PSP).
Even if:
- You never touch the money
- You only pass API calls
- You act as “middleware”
Legally, you are in the payment flow.
Which means:
- You need PSP licenses
- You fall under central bank regulation
- Aggregators can block you for “reselling” their infrastructure
- Settlement logic makes you a financial intermediary
In CEMAC, this is enforced under Commission Bancaire de l'Afrique Centrale (COBAC) oversight.
We weren’t building a developer tool.
We were accidentally building an unlicensed financial institution.
❌ The Failures We Caught Early
1. Automatic Failover Is Not Allowed
Our proudest feature:
If Campay's MTN API fails → automatically retry with Tranzak's MTN API
Sounds smart. Completely illegal in practice.
Why? Merchants are KYB’d per provider. You can’t reroute their transactions without explicit registration.
2. Settlement Scheduling Makes You a PSP
We planned:
“UAPL pays out to developers on a schedule”
That single sentence legally converts you into a money handler.
Instant PSP classification.
3. Aggregators Can Shut You Down Overnight
Platforms like Flutterwave or Campay can decide you are “reselling” their API as a platform.
They don’t need to argue. They just revoke your keys.
Game over.
4. The Illusion of “One License for Many Countries”
We assumed:
Get a CEMAC license → operate everywhere in the zone
Reality:
- Country-level approvals
- Telco-level approvals
- Data residency considerations
- Central bank notifications
A regional license is not a passport. It’s permission to start more paperwork.
🧩 The Big Realization
We thought we were building:
Stripe for African mobile money
But what we needed to build was:
Stripe.js for African mobile money
A critical difference.
One is a regulated payments company.
The other is a developer SDK.
🔁 The Pivot
We redesigned UAPL to be:
- A pure SDK and orchestration library
- Developers bring their own provider credentials
- No routing of funds
- No settlement
- No payout control
- No position in the legal payment chain
Now, that designs UAPL as a software. Not fintech.
And that version is legally unstoppable.
🧭 Lessons for Developers Building in Fintech
Before writing code, answer these:
- Who is the regulator in this space?
- Does my system decide where money goes?
- Does my system delay, batch, or settle funds?
- Am I unintentionally “intermediating” transactions?
If yes, you are not building a tool.
You are building a financial institution.
🗣️ Why I’m Sharing This
Because from an engineering standpoint, this was one of the best systems we’ve ever designed.
And it still would have failed.
Not due to bugs.
Not due to scaling.
Not due to product-market fit.
But because we didn’t start with regulatory research.
If you’re a developer building in Africa’s fintech space, learn from this before you spend months building the wrong thing.
Research first. Architect second. Code third.
