Digital Wallet & Payment Platform

The problem

It is a wallet and payment-service platform: customers hold balances, send money, cash out through agents, pay merchants, top up phones, settle bills and move money to and from banks. It also has to reach the card networks, satisfy KYC, and produce numbers a central bank will accept.

That is not one product. It is a dozen products sharing a balance, and the architecture reflects that — roughly thirty-two services in the core group alone, with more across bill payment, cards, USSD, school payments and the admin portals.

Shape of the system

wallet platform / service estate

The estate divides cleanly into three bands, and the discipline is in not letting them blur:

• Edge — an aggregator gateway and per-client gateways, two-factor auth, device binding, and a discovery service so nothing hardcodes a peer’s address.
• Transaction capabilities — send money, cash-out, payment, external fund transfer, top-up, merchant, ewallet. Each owns one kind of money movement.
• Platform services — deduplication, unique-ID generation, notification, scheduler, file, metadata, Kafka transport, transaction analytics.

Underneath all of it sits Apache Fineract as the core banking system, holding the general ledger, journal entries and end-of-day.

Why this is a microservice estate and the billing pipeline is not

I have built both, and the honest answer is that the shape follows the risk, not the fashion.

The invoice pipeline is five services because a billing run has five genuine stages, and its problem is throughput. This platform is thirty-two because a payments product has thirty-two genuinely different failure and compliance profiles. Cash-out is the highest-fraud path in any MFS product; send-money is the highest-volume; external fund transfer touches an external bank and inherits its downtime. Putting those in one deployable means every release carries the risk of all three.

That is the argument for splitting. It is also the whole cost: thirty-two services means thirty-two pipelines, and a transaction that spans several of them has no database transaction to hide behind.

Where I worked

I want to be precise about scope rather than claim the estate.

My work concentrated on the money-truth layer — the wallet core service and its integration with Fineract — and on the release line:

• General-ledger account statements surfaced out of Fineract, so a balance shown to a customer and a balance in the core banking system are the same number with the same derivation.
• End-of-day CBS reporting and payment-type handling — the daily close where discrepancies either surface or compound silently.
• Transaction reversal across the platform, implemented as compensating entries so history stays intact and reconciliation stays possible.
• Repository maintainer on the wallet core and portal repositories: reviewing and approving what entered the release branch of a system that moves other people’s money.

That last one is not a coding contribution and it mattered more than the others. On a thirty-two service estate, the release line is the architecture — it is the only place where the whole platform is considered at once.

The lesson I would carry to the next one

Distributed money movement makes you confront a thing monoliths let you avoid: there is no transaction boundary around a business operation. A cash-out spans several services, and no database will roll it back for you.

What actually holds it together is unglamorous: centralised idempotency so retries are safe, globally unique references so every leg is traceable, compensating entries so mistakes are reversible, and end-of-day reconciliation to catch what all of that still missed. Those four are the real architecture. The service boundaries are just where you drew the lines.