← All work
Case study 01 · Velofi

Fintech railswhere retries cannever pay twice.

Role
Backend Software Engineer
Timeline
2026 — present
Engagement
Hybrid · contract
Stack
TypeScript · Node.js · PostgreSQL · Redis · Docker · Jenkins
0
duplicate financial operations from retries or network failures
1
device per account; new devices need email approval and a WhatsApp code
E2E
onboarding, from registration to a funded-ready account
Auto
partner notifications via ZeptoMail, replacing manual email
The situation

Velofi is a fintech platform: people sign up, get verified, receive an account and invest — with monthly and annual returns paid out on schedule. Every one of those steps moves real money or real identity data, across a microservices architecture and several external financial partners.

I built the backend paths that carry users from first registration to a funded-ready account, and the investment workflows that pay them — designed so that a retry, a timeout or a flaky network can never produce a second financial operation.

What I changed
  1. 01

    Onboarding & provisioning

    Problem
    Users had to be verified and given usable accounts, through external financial processors, without manual steps.
    Result
    Registration, auth, BVN verification, customer tiering and account provisioning — end to end, to a funded-ready account.
  2. 02

    Idempotent payouts

    Problem
    Scheduled monthly and annual returns are exactly where retries and network failures cause double payments.
    Result
    Investment and returns workflows built on idempotency keys, so no retry ever produced a duplicate financial operation.
  3. 03

    One device at a time

    Problem
    A stolen password shouldn't be enough to get into someone's account and money.
    Result
    Each sign-in gets a device token held in Redis. A new device needs the owner's email approval and a one-time WhatsApp code; then it's trusted and the old device is signed out. Operations teams get granular admin roles.
  4. 04

    Partner APIs & notifications

    Problem
    External partners needed programmatic access, and customer emails were being handled by hand.
    Result
    API-key and webhook integrations across the microservices, and automated ZeptoMail notifications that removed the manual email work.
What I learned
“In fintech the happy path is the easy part. The real design work is deciding what happens on the second attempt — and making sure the answer is always "nothing".”
Next case study
Fixr — Backend Software Engineer
© 2026 Akwolu Innocent ChinweikeBuilt with Next.js · Framer MotionBack to top ↑