Gecko Labs · Payments and group savings

Zetu

A wallet and group savings engine for pan-African payments

01

What it is

Zetu is Swahili for “ours”, and the product starts where a great deal of African saving already happens: the group pot. Members pay in on a cycle, one member is paid out, and the ledger has to be right every time or the group stops trusting it.

The application core is wider than the demo, and the two are worth separating. The core covers a single wallet with top-ups, transfers, withdrawals, scheduled payments and transaction history; group pots with joining, contributing and rotating or democratic payout, with per-cycle deduplication so a double contribution cannot be double counted; and escrow as an explicit state machine with release, dispute and refund paths and a 72 hour dispute window. Merchant onboarding and QR payment sit behind a feature flag.

What the demo lets you drive is a path through that core, not all of it: signing in as a seeded member, reading the account panel, sending one transfer to another member, contributing to the group pot, and pressing the blocked transfer. There is no top-up, no withdrawal, no scheduled payment, no transaction history view, no joining or leaving a pot, no payout and no escrow in front of you. Those are in the code and are exercised by its own tests; they are not on screen here.

Underneath, every movement is a double entry, every state change writes into a hash-chained audit log that can verify its own chain, and every external call goes through a timeout and a circuit breaker. Sessions are opaque bearer tokens hashed at rest, and every route carries object-level authorisation rather than trusting the caller’s claim about who they are. The layer boundaries of the architecture are checked mechanically in CI, so the domain cannot acquire a dependency on the database by accident.

What it is not: a licensed or operating payment service. No real money moves, and the default rail is a sandbox that labels every settlement as simulated. AML screening is running: it is what refuses the R900 000 transfer in the walkthrough below, before the debit, and it does not tell the sender which rule fired. What is switched off in the build you are looking at is credit scoring and lending, which is where a regulator’s permission would be needed.

02

What to watch for

  1. Sign in as a member. Requesting a code calls the real one-time-password route, and the demo notifier hands the code straight back instead of sending a message.

  2. Read the account panel. Those balances were seeded when the service booted. Nothing was deposited.

  3. Send a small amount to another member. The movement is recorded as a double entry, not as a balance edit.

  4. Contribute to the group pot and watch the cycle, the monthly figure and the amount still owing change together.

  5. Press "Try R900 000". Compliance screening runs before the debit, refuses it, and does not tell the sender which rule fired.

03

Open it

Before you start The demo runs on Cloud Run and scales to zero, so the first load can take a few seconds while the service starts. Balances are seeded demo data and the payment rail is simulated.