Payment Infrastructure & Merchant Platform for a Nigerian Fintech
Overview
I was part of the engineering team that built a Nigerian fintech platform from the ground up as a PHP application before the backend was later decomposed into a microservices architecture.
Following the transition to microservices, I continued maintaining and extending the platform while taking ownership of new Java-based merchant applications. My work spanned backend development, financial integrations, authentication and authorization, distributed-system communication, data replication, security, and development infrastructure.
The wider platform supports ₦106M+ in monthly transaction volume across 7,500+ transactions, with integrations across external financial services generating 763K+ provider API calls.
The Challenge
The platform evolved from a monolithic backend into a distributed microservices architecture as its functionality and operational requirements grew.
This created a different class of engineering problems.
The new merchant applications needed to interact with multiple backend services while presenting merchants with a consistent experience across the web dashboard and POS terminals.
One of the most important challenges I worked on was merchant identity management across different onboarding paths and distributed services.
Merchant onboarding could happen through two paths
Regular onboarding / account upgrade
A merchant could originate from the normal user onboarding flow and subsequently be upgraded into a merchant.
TID upload
Merchant information could also be created through a terminal/TID-based onboarding process.
Despite having different onboarding paths, both types of merchants needed to use thesame credentials to access:
- the external merchant dashboard
- the POS terminals assigned to them
The challenge was that merchant-facing applications and POS functionality were backed by the microservices platform. Authentication therefore couldn't simply live independently inside each application.
We needed a centralized authentication and authorization model that could establish one merchant identity across the distributed system.
My Contribution
Continued development through the architectural transition
I was part of the team that built the original platform from the ground up before it was broken down into microservices.
After the migration, I continued maintaining the distributed backend and extending the system with new services and applications.
This gave me experience working across both sides of the architectural transition:
That distinction is important because the work wasn't simply greenfield microservices development; it involved understanding an existing business system while continuing to deliver functionality during architectural change.
Built the Merchant and Super Merchant applications
I independently built the backend services for the Merchant andSuper Merchant applications using Java.
These applications provide different operational capabilities:
Merchant application
Designed for individual merchants to interact with their account and operational information.
Super Merchant application
Designed for higher-level merchant/aggregator operations and management across multiple merchants.
I was responsible for the backend implementation of these applications, including their integration with the existing microservices ecosystem.
Centralized merchant authentication and authorization
The most interesting problem was ensuring that merchants had a consistent identity across the platform despite multiple onboarding mechanisms and distributed services.
Rather than allowing each application to maintain its own independent authentication state, I designed the merchant applications around the existing microservices authentication model so that authentication and authorization could be handled centrally.
Merchant Identity
│
Central Authentication
│
┌──────────────┴──────────────┐
│ │
▼ ▼
Merchant Dashboard POS Terminal
│ │
└──────────────┬──────────────┘
▼
Microservices
Authorization LayerThis allowed the same merchant credentials to be used across the merchant-facing systems while keeping authorization under a centralized backend model.
Why this mattered
Without a consistent identity model, separate onboarding paths could result in:
- duplicated identities
- inconsistent credentials
- conflicting authorization rules
- difficult account management
- disconnected dashboard and POS access
The solution instead treated the merchant as a single platform identity, regardless of how the merchant entered the system.
Financial integrations
I worked on integrations with banks and NPS-related services to support financial operations within the platform.
These integrations required the backend to communicate with external financial systems while keeping provider-specific behavior isolated from the rest of the application.
The work contributed to a platform supporting transaction processing and financial operations at scale. The broader platform currently processes ₦106M+ in monthly transaction value across 7,500+ transactions.
Near-real-time data distribution using PostgreSQL logical replication
The merchant and super merchant applications needed access to information originating from multiple microservices.
Rather than making every dashboard request travel through several services for read-heavy operations, I used PostgreSQL logical replication to make selected data available to the applications more efficiently.
Microservice Database
│
│ Logical Replication
▼
Read-Optimized Data
│
▼
Merchant / Super Merchant APIs
│
▼
DashboardsThis allowed selected data to be transferred from the source services into a database optimized for consumption by the merchant applications.
The approach was particularly useful for dashboard-oriented workloads where fast access to frequently viewed information was more important than repeatedly querying operational services.
Development infrastructure with Oracle Cloud
Oracle Cloud was not the company's production infrastructure in this context.
I used Oracle Cloud personally as a development environment to run containerized workloads that would otherwise place significant load on my local machine.
Running multiple services and containers locally caused my development machine to lag and overheat, so I offloaded container workloads to cloud compute resources while retaining my local IDE-based development workflow.
Local Development Machine
│
IDE / Code
│
▼
Remote Dev Host
(Oracle Cloud)
│
┌─────────┼─────────┐
▼ ▼ ▼
Service A Service B Database
Container Container ContainerThis separated development and execution resources, allowing me to work against a multi-service environment without putting the entire workload on my local computer.
I also gained practical experience with cloud compute, networking, storage, and containerized development as part of this setup.
Architecture
The platform evolved through two major architectural stages.
Stage 1 — Monolithic foundation
The original system was built as a PHP application, with core business functionality operating inside a single backend.
Stage 2 — Microservices architecture
The system was subsequently decomposed into independently managed services.
Client Applications
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
Merchant Super Merchant POS
Dashboard Dashboard Devices
│ │ │
└────────────┼────────────┘
▼
Microservices Layer
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
Transactions Merchant/Auth Financial
& Operations Services Integrations
│ │ │
└─────────────────┼─────────────────┘
▼
PostgreSQL Databases
│
Logical Replication
▼
Application Read LayerArchitecture details have been generalized to protect proprietary implementation information.
Results & Scale
The work formed part of a platform currently operating at meaningful financial and API scale:
The broader platform metrics are reflected in my professional experience.
Engineering Takeaways
Distributed systems change the authentication problem
Moving functionality into microservices does not automatically solve identity management.
When multiple applications and devices need to represent the same business entity, authentication and authorization have to remain consistent across service boundaries.
In this case, merchant identity needed to work across different onboarding paths, the external dashboard, and POS access.
Read-heavy applications don't always need to query operational services directly
Merchant dashboards often need large amounts of data for reporting and operational visibility.
Using logical replication provided a way to make selected data available closer to the consuming applications without forcing every dashboard operation through transactional services.
Architecture evolution requires continuity
The system wasn't created as microservices from the beginning.
It evolved from a PHP monolith into a distributed platform.
Working through that transition taught me how architectural modernization differs from starting a greenfield system: existing behavior, data, integrations, and business operations still have to keep working while the architecture changes underneath them.
Technology
Backend
Java, PHP legacy systems, REST APIs, gRPC
Databases
PostgreSQL
Distributed Systems
Microservices, logical replication
Infrastructure
Docker, Kubernetes, Oracle Cloud
CI/CD
GitHub Actions, Argo CD
Observability
Prometheus, Grafana
Frontend contribution
Next.js
My Role at a Glance
Built
Core backend components, merchant applications, financial integrations
Owned
Merchant and Super Merchant backend services
Solved
Cross-system merchant authentication and authorization
Worked with
Microservices, financial integrations, logical replication, cloud-based development infrastructure
Environment
Production fintech platform
Building a transaction-heavy product?
Chelon Labs helps fintechs and growing technology companies build and modernize backend systems, financial integrations, and cloud infrastructure.
Discuss your project