Two worlds of money
If you build payments for Africa, you build for mobile money. In Ghana a phone number is a wallet; MTN MoMo moves more value than the card networks ever will. Build the same product for Canada, the US, or Europe and none of that applies — there it's cards, Apple Pay, Google Pay, and bank payouts.
Most platforms pick a side. A Silicon Valley payments API treats mobile money as an afterthought, if it supports it at all. An African fintech wires MoMo beautifully and then can't touch a Canadian card. Pick wrong for a given market and you've built a wall your users have to climb.
We didn't want to pick. So we built two rails behind one API.
The rails
- The African rail — MTN Mobile Money. Collections and disbursements against a
phone number, the way money actually moves in Ghana. It's the primary rail for the markets we're built for first.
- The global rail — Stripe. Cards, wallets, and payouts, **wherever Stripe is
supported** — the US, Canada, the UK, the EU, and beyond. Fund a wallet by card, cash out to a bank or debit card via Stripe Connect with per-country routing.
Same request shapes, same identity, same ledger underneath. A developer integrates once; the platform routes to the rail that fits the money and the market — not the other way around.
Why both, and not one
This is the practical face of a decision that runs through everything we build: Danipa is built for Africa first, but software has no borders.
We're a Canadian company — twenty years this November — that chose to solve African technology needs because the rest of the industry doesn't devote the resources to. But the code we write to move money securely in Accra works just as well in Toronto or London. Restricting it to one geography would waste that; so would pretending we're a generic global processor and losing the thing that makes us useful. The dual-rail design lets both be true: deep where it's hardest, open everywhere else.
There's a sequencing reason too. Production launches in Canadian dollars first — the Stripe rail — because that's how we raise the capital to fund the African build. The MoMo rail is what that capital is for.
Under the hood
The rails sit behind a provider model, not baked into the core. Adding a new country's rail is a new provider implementation, not a re-architecture — the identity layer, the double-entry ledger, the webhook and idempotency machinery, and the security posture are shared. Orange Money and Wave already exist as collection and disbursement providers for the francophone markets we're sequencing next; remittance today settles to MTN Mobile Money in Ghana.
For developers it's one surface. A remittance is a single POST to /ms/v1/remittance/transfer; you track it with a GET on its status. The four SDKs — Java, Node, Python, PHP — wrap the same endpoints. The developer sandbox is open, and the developers page has the callable examples.
Where this is today
Honestly: on the sandbox. Card fund-in runs there; MoMo is wired for Ghana; Stripe Connect payouts are built and being hardened; the corridor we exercise end-to-end is CAD → GHS. There's no production environment and no real money moving yet — that comes post-funding. But the two-rail spine is real, and it's the reason a merchant in Kumasi and a developer in Kitchener can build on the same platform.
Two rails. One API. See how it fits together.