NetBet

Context

NetBet is the Uganda deployment: a full sportsbook and casino serving a single market. I worked on the backend — the services behind accounts, betting, settlement and the wallet, plus the payment integrations that connect it to how people in Uganda actually move money.

A single-market platform sounds simpler than a multi-country one, and in one sense it is. What it removes in configuration complexity it hands back in specificity: one currency, one regulator, one set of payment rails, and no ability to hide a bad assumption behind a per-market override.

The problem

The interesting constraints were on the money path.

Most deposits and withdrawals here run through mobile money, not cards. That changes the failure model. A card gateway either authorises or declines, usually inside a second. A mobile-money transaction is asynchronous: the platform initiates, the user confirms on their handset, and a callback arrives at some point afterwards — or doesn't, or arrives twice, or arrives after the user has already given up and retried.

Any wallet built on the assumption that a payment resolves synchronously will eventually double-credit somebody or lose a deposit. Those are the two failure modes that actually matter, because one costs money and the other costs trust.

What I built

Payments. Provider integrations for deposits and withdrawals against local mobile-money rails, built around the assumption that callbacks are unreliable by default. Every transaction carries an idempotency key, so a provider retrying a webhook credits an account once and not three times. Callback signatures are verified rather than trusted. Pending transactions reconcile against the provider rather than sitting in limbo waiting for a callback that may never arrive.

The ledger. Amounts stored in minor units against an explicit currency, never as floats. UGX has its own conventions, and a ledger that is vague about what a number means is a ledger that will eventually be wrong in a way nobody can reconstruct.

Services. Go and Spring Boot services for accounts, betting, settlement and wallet operations, communicating over gRPC internally and REST at the edge — the same service patterns as the rest of the platform stack, so operational knowledge transfers between markets instead of being relearned.

Streaming. Domain events published to Kafka, feeding the same downstream consumers used for monitoring and fraud detection elsewhere on the stack.

Impact

• A live sportsbook and casino running in Uganda on the shared platform stack.
• Payment flows that survive the realities of mobile money — retried callbacks, delayed confirmations and user retries — without double-crediting or silently dropping deposits.
• Backend patterns consistent with the other markets, so a fix made once applies broadly rather than being reimplemented per country.

What I'd revisit

Provider integrations were built one at a time as each rail came online, which left more shape in common between them than the code currently admits. A single provider abstraction with per-provider adapters would make the next integration substantially cheaper — the pattern was visible by the second one, and that was the moment to consolidate.