MonieWorld: Engineering a Global Fintech Platform

Project Overview

MonieWorld is a cross-border payments platform for transfers from the UK to destinations worldwide. Moniepoint, Nigeria’s leading payment provider and a fintech unicorn, launched it to compete directly with Wise.

As founding senior frontend engineer, I built the frontend from scratch and set the patterns the rest of the team built on. It launched supporting only UK to Nigeria transfers, but we architected it to scale globally from day one, and that single requirement shaped almost every technical decision I made after.

Key Metrics & Impact

• £50 million+ processed in cross-border transfers since launch.
• 99.6% transaction success rate maintained across all payment flows.
• 90% reduction in production bugs through our testing strategy.
• 55% increase in payment success rate after digital wallet integration (Apple Pay, Google Pay).
• Sub-second page load times for all critical user journeys.
• 90% unit test coverage (Jest) and 95% E2E test coverage (Playwright) for critical flows.
• Zero security incidents in card management and sensitive data handling.

Tech Stack

Frontend Core

• Framework: Next.js 14 (App Router) with React 18
• Language: TypeScript (100% type-safe codebase)
• Styling: TailwindCSS with custom design system (Kamona UI)
• State Management: TanStack Query (React Query) for server state
• Forms: React Hook Form with Zod validation

Testing & Quality

• Unit/Integration: Jest + React Testing Library
• E2E & BDD: Playwright with Cucumber
• Code Quality: SonarQube, ESLint, Prettier

Build & Deployment

• CI/CD: Jenkins pipeline with automated quality gates
• Containerization: Docker with Kubernetes (K8s)
• Monitoring: New Relic APM for performance tracking

APIs & Integration

• API Layer: RESTful APIs with Axios interceptors
• Authentication: JWT with 2FA (OTP-based)
• Payment Gateways: Open Banking VRP, Apple Pay, Google Pay, card processors

Architecture & System Design

Domain-Driven Design for Scalability

I championed a feature-based architecture using Domain-Driven Design principles to organize 50+ features into clear bounded contexts (Payments, Recipients, Cards, VAS, etc.). This enabled parallel development, reduced cognitive load, and allowed the team to scale without degradation.

Feature Organization (50+ Features):

monieworld/
├── src/features/                    # Core domains (bounded contexts)
│   ├── payments/                   # Payment processing domain
│   │   ├── send-money/            # Cross-border transfers
│   │   │   ├── select-recipient/
│   │   │   ├── enter-amount/
│   │   │   ├── select-payment-method/
│   │   │   └── review-transaction/
│   │   ├── add-money/             # Account funding
│   │   │   ├── select-method/
│   │   │   ├── payment-providers/
│   │   │   └── success/
│   │   └── transactions/          # Transaction history & details
│   │       ├── transaction-list/
│   │       ├── transaction-details/
│   │       └── transaction-filters/
│   ├── recipients/                 # Recipient management domain
│   │   ├── recipient-list/        # List view with filters
│   │   ├── add-recipient/         # Add new recipient
│   │   │   ├── add-recipient-ng/  # Nigeria-specific
│   │   │   └── add-recipient-gb/  # UK-specific with COP
│   │   ├── edit-recipient/        # Edit existing recipient
│   │   ├── recipient-details/     # Details and insights
│   │   └── recipient-transactions/ # Transaction history per recipient
│   ├── cards/                      # Card management domain
│   │   ├── home/                  # Card overview & management
│   │   │   ├── card-carousel/
│   │   │   ├── card-actions/
│   │   │   └── delivery-status/
│   │   ├── manage/                # Card actions (freeze, unfreeze)
│   │   └── replace/               # Card replacement flows
│   ├── vas/                        # Bill payments domain (dynamic)
│   │   ├── amount/                # Amount selection (dynamic)
│   │   ├── recipients/            # VAS recipient management
│   │   ├── review/                # Transaction review
│   │   └── shared/                # Shared VAS utilities
│   ├── accounts/                   # Account management domain
│   │   ├── registration/
│   │   ├── profile/
│   │   └── security/
│   ├── onboarding/                 # KYC domain
│   │   ├── identity-verification/
│   │   ├── document-upload/
│   │   └── compliance-checks/
│   ├── settings/                   # User settings domain
│   ├── support/                    # Customer support domain
│   │   ├── feedback/
│   │   ├── help-center/
│   │   └── zendesk-integration/
│   └── shared/                     # Shared domain features
│       ├── recipient/             # Cross-feature recipient utilities
│       ├── transaction/           # Cross-feature transaction utilities
│       ├── payment-method/        # Payment method abstractions
│       └── validation/            # Shared validation rules
├── ui/                             # Design system components
│   ├── forms/
│   ├── layouts/
│   ├── notifications/
│   └── data-display/
└── lib/                            # Infrastructure & utilities
    ├── api-config/
    ├── analytics-service/
    ├── feature-flags/
    ├── cookie-consent/
    └── telemetry/

Zero-Code Bill Payment System (VAS)

Designed a completely backend-driven bill payment system where all form fields, validations, and UI elements are configured server-side. This enabled:

• Zero deployment time for new bill payment providers.
• Business team autonomy to add providers without engineering involvement.
• 90% reduction in development time for new payment categories.

Secure Card Management Architecture

Implemented a secure card viewing system with multiple layers to meet PCI-DSS compliance:

• End-to-end encryption for card details.
• 2FA verification before viewing sensitive information.
• Automatic data purging from memory after timeout.
• Complete audit logging.

Testing Infrastructure

Pioneering Behavior-Driven Development (BDD)

As the first engineer to implement BDD, I established company-wide testing standards:

• 46 feature files covering all critical user journeys.
• 95% E2E coverage for Payments, Cards, and VAS modules.
• Reusable step definitions for authentication, payment flows, and form interactions.

CI/CD with Rigorous Quality Gates

Implemented a Jenkins pipeline enforcing:

• 90% minimum unit test coverage.
• Zero TypeScript errors.
• All E2E tests passing for critical flows.
• No high/critical security vulnerabilities.

Key Technical Challenges

1. Multi-Country Recipient Validation

Built a complete recipient management system handling:

• UK recipients: COP (Confirmation of Payee) validation with real-time verification.
• Nigeria recipients: Bank code and account number validation.
• Multi-currency support: Recipients in GBP, NGN, USD, and other currencies.
• Smart filtering: Search across thousands of recipients with transaction insights.

2. Variable Recurring Payments (VRP) Integration

Implemented Open Banking VRP to enable higher transaction frequency, saved bank accounts, and compliance with UK Open Banking standards.

3. Dynamic Form Generation Engine

Built a runtime form generation system for bill payments, with type-safe rendering driven entirely by backend configuration. Adding a new provider needed zero frontend code changes.

Payment Flow Architecture

Architected the full payment journey:

1. Recipient Selection: With saved recipients, COP validation, and smart filtering.
2. Amount Calculation: Real-time exchange rates, transparent fees, multi-currency input.
3. Payment Method Selection: Saved bank accounts (VRP), cards, Apple/Google Pay, bank transfers.
4. Transaction Processing: Real-time status updates with 1-second polling, full error handling, and receipt generation.

Implemented polling that stops automatically once a transaction reaches a terminal state, instead of polling forever.

Results & Business Impact

Platform Performance & Reliability

• Shipped 4 major modules (Payments, Recipients, Cards, VAS) from the first line of code to production.
• Maintained 99.6% transaction success rate and sub-second page loads.
• Achieved zero critical bugs in production for security-sensitive features.

Business Growth Enablement

• VRP & Saved Methods: Increased transaction frequency and customer retention.
• Dynamic VAS System: Opened a new revenue stream that doesn’t need engineering work to extend.
• Digital Wallets: Drove a 55% increase in payment success rate.
• Secure Card Management: Enabled card product launch by meeting PCI-DSS compliance.

Team & Process Leadership

• Established BDD practices and testing standards adopted company-wide.
• Built architectural foundations enabling team scaling from 1 to multiple engineers.
• Mentored team members on testing, architecture, and code quality best practices.

Key Learnings

Regulatory compliance and good UX aren’t in tension if you design the layers carefully. PCI-DSS didn’t force a clunky card experience, it just meant the 2FA and auto-purge logic had to be right the first time.

The backend-driven VAS system took longer to build than a hardcoded version would have. It paid for itself the first time the business team shipped a new bill payment provider without filing an engineering ticket.

90% unit coverage and 95% E2E coverage on critical flows sound like a lot of overhead until you’ve shipped a refactor with that safety net under you. That’s where the 90% drop in production bugs actually came from, not from writing more careful code.

Domain-Driven Design meant a new engineer could own the Cards module without reading the Payments module first. That’s the real point of bounded contexts: not elegance, just letting people work without stepping on each other.

Tech Stack Summary

Frontend Framework

• Next.js 14 (App Router)
• React 18
• TypeScript (100% type-safe codebase)

Architecture & Design

• Domain-Driven Design (50+ feature domains across Payments, Recipients, Cards, VAS)
• Feature-based architecture with bounded contexts
• Component-driven development

Styling & UI

• TailwindCSS utility-first framework
• Kamona UI custom design system
• Responsive mobile-first approach

State Management

• TanStack Query (React Query) for server state
• React Context for global client state
• URL state management for navigation persistence

Forms & Validation

• React Hook Form for performant form handling
• Zod for runtime type validation and schema definition
• Custom validation hooks for business logic

Testing Suite

• Jest for unit/integration testing (90%+ coverage)
• React Testing Library for component testing
• Playwright for E2E testing
• Cucumber for Behavior-Driven Development (BDD)
• Mock Service Worker (MSW) for API mocking

CI/CD & DevOps

• Jenkins for CI/CD pipeline automation
• Docker for containerization
• Kubernetes (K8s) for orchestration
• Automated quality gates and test execution
• Feature flag management

Payment Integrations

• Apple Pay SDK integration
• Google Pay SDK integration
• Open Banking Variable Recurring Payments (VRP)
• Multiple card payment processors
• Bank transfer and direct debit options

Monitoring & Observability

• New Relic APM for application performance monitoring
• Custom logging and error tracking
• Real-time transaction status monitoring

API Layer

• RESTful APIs with consistent error handling
• Axios interceptors for request/response management
• JWT authentication with 2FA (OTP-based)
• Rate limiting and request throttling

Code Quality & Standards

• SonarQube for code quality analysis
• ESLint with custom rulesets
• Prettier for code formatting
• Git hooks for pre-commit checks

Third-Party Services

• Zendesk for customer support integration
• Mixpanel for product analytics
• Customer.io for lifecycle messaging
• Singular for attribution tracking

Conclusion

Domain-Driven Design and the backend-driven VAS system are the two decisions I’d point to if asked what mattered most here. Both took longer to build than a quick version would have, and both paid for themselves within months once the team grew past me.

£50M+ processed, a 99.6% success rate, and a 90% drop in production bugs are the numbers that matter to the business. What I actually care about is that four other engineers joined this codebase after me and shipped features without needing me to explain how any of it worked. That’s the real test of whether an architecture was worth the extra time it took to build.