Skip to content

Have something in mind?

Let’s talk

Product Engineering

Frontend Engineering

Airbenda

Airbenda is a Nigerian fintech platform that enables businesses to accept payments funded through mobile airtime.

As a Frontend Engineer at Serendpt AI, I independently developed three applications powering different parts of the platform: the merchant application, the internal administrative console, and the customer-facing checkout.

My responsibility was to turn the existing payment APIs and business requirements into usable, maintainable frontend applications. This involved implementing authentication, multi-tenant merchant workflows, transaction management, operational dashboards, payment interfaces, and the frontend safeguards needed when working with financial data.

Live preview(opens in a new tab)

Project details

Project type
Fintech & Payment Platform
Role
Frontend Engineer — Sole Frontend Engineer
Engagement
Part-time Employment (Serendpt AI)
Period
Sept 2026 – Present
Status
Ongoing Development
Technologies
  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • TanStack Query
  • React Hook Form
  • Zod
  • Base UI
  • Recharts
  • GSAP
  • Lenis
  • REST APIs

Context

Project context.

Airbenda provides an alternative payment method that allows customers to pay merchants using mobile airtime.

Supporting that payment experience requires more than a checkout page. Merchants need to manage accounts, monitor transactions, request payouts, and configure payment destinations. Internal operators need tools to investigate transactions, manage receiving infrastructure, and review financial operations. Customers need clear instructions and reliable information while payments are being processed.

The platform addresses these requirements through three separate frontend applications connected to a common backend.

Project setting

I was the sole frontend developer across the merchant, admin, and checkout applications.

The applications were developed as separate Next.js projects and integrated with a shared Python/FastAPI backend maintained by other engineers.

My ownership covered the frontend architecture, application interfaces, frontend API integrations, and associated workflows—not the backend payment-processing, settlement, accounting, or airtime-matching services.

Problem space

  • Merchants needed a complete payment management experience.

    Business users required a central application for registration, verification, transaction monitoring, payment links, team management, and account configuration.

  • Internal operations required dedicated interfaces.

    Administrators needed platform-wide visibility into transactions, payouts, verification requests, SIM inventory, and financial records, with carefully controlled actions for sensitive workflows.

  • Airtime payments introduced complex checkout states.

    Unlike an immediate card-payment response, airtime transfers may take time to be recognized. Customers need to understand the correct amount, receiving number, remaining time, partial payments, and eventual payment status.

  • Different user groups needed consistent integration with the same backend.

    The three applications serve different audiences but depend on related payment data and API contracts. Each frontend needed appropriate authentication, validation, error handling, and state management.

Target users

  • Merchants: Businesses accepting airtime payments and managing their payment operations.
  • Merchant teams: Finance, support, developer, and administrative users working within organizations.
  • Platform administrators: Internal staff responsible for transaction oversight, operational reviews, verification, and receiving infrastructure.
  • Customers: People completing airtime-funded payments through hosted checkout pages.

Contribution

My contribution.

Frontend Engineer — Sole Frontend Developer

I independently implemented all three frontend applications, translating product requirements and existing backend capabilities into functional interfaces.

My work spanned application architecture, feature development, API integration, frontend state management, access-aware user experiences, and operational error handling.

  1. Built the Merchant Application

    I developed the merchant-facing application, combining a public marketing website with authenticated business operations.

    The application supports merchants from initial registration and account verification through day-to-day payment management.

    Key features I implemented included:

    • Merchant registration, email verification, login, and password recovery.
    • Multi-step individual and business verification workflows with document uploads.
    • Dashboard views displaying balances, transactions, and operational summaries.
    • Transaction filtering, pagination, and payment-status presentation.
    • Manual reconciliation review interfaces.
    • Payout request and tracking workflows.
    • Payment link creation and management interfaces.
    • Subscription management interfaces.
    • Organization switching, team invitations, and role-based access controls.
    • Account settings, webhook configuration, integration credentials, and data exports.

    A significant part of the implementation involved handling organization-specific access and data correctly.

    Rather than relying solely on hidden interface controls, I incorporated permission checks into frontend server actions and separated cached data by organization context.

  2. Developed the Administrative Application

    I built a separate internal operations console for Airbenda administrators.

    Unlike the merchant application, this interface presents platform-wide operational information and workflows intended for authorized staff.

    Its functionality includes:

    • Administrator authentication and protected application access.
    • Operational dashboards with transaction summaries and visualizations.
    • Transaction investigation with filtering and pagination.
    • Reconciliation and payout tracking interfaces.
    • Transfer approval and rejection workflows.
    • Individual and business verification review.
    • Customer account inspection and suspension interfaces.
    • Receiving SIM inventory management.
    • Financial journal, summary, and unmatched-credit review interfaces.
    • Compliance-related review interfaces.
    • Reporting configuration and preview interfaces.

    The administrative application required additional attention to sensitive actions.

    For example, when an operator records an externally verified payout settlement, the frontend re-fetches the relevant record and checks that important details have not changed since the confirmation dialog was opened.

    I implemented similar safeguards around other financial review workflows, including explicit confirmations, validation, partial-result reporting, and handling ambiguous API responses without automatically repeating potentially sensitive operations.

  3. Built the Hosted Checkout Application

    I independently developed the customer-facing checkout application used when a customer initiates an airtime payment.

    The checkout supports direct payment requests and hosted payment links, collecting relevant payer information before initializing a payment session.

    The implementation includes:

    • Validation of merchant payment parameters and checkout links.
    • Payer information collection.
    • Fixed and customer-entered payment amounts where supported.
    • Payment initialization and session management.
    • Display of receiving phone numbers, payment amounts, and charges.
    • Payment status polling and countdown timers.
    • Partial-payment and outstanding-balance presentation.
    • Payment confirmation, cancellation, and recovery interfaces.
    • Success screens and return navigation to merchant websites.

    One of the most important engineering concerns was ensuring that the interface never treated a customer's confirmation as proof of settlement.

    The checkout displays the backend's payment status and waits for the appropriate confirmed outcome rather than marking a transaction successful locally.

    I also implemented safeguards against duplicate session initialization and outdated API responses overwriting newer payment information.

  4. Developed the Public Marketing Experience

    Alongside the merchant dashboard, I implemented Airbenda's public website.

    This included product information, merchant and customer use cases, pricing presentation, and onboarding pathways.

    The implementation uses responsive layouts and GSAP-powered interactions, with Lenis and reduced-motion handling for the marketing experience.

    The marketing website and authenticated merchant functionality share one Next.js application, while the admin and checkout applications remain separate projects.

Scope of ownership

Airbenda is one of my broader frontend engineering engagements because it required ownership of three applications serving distinct users and operational responsibilities.

Rather than focusing on isolated screens, I worked across complete product workflows—from business registration and organization management to payment monitoring, internal financial operations, and customer checkout.

The project demonstrates my ability to independently structure and deliver complex React and Next.js applications, integrate existing backend systems, handle sensitive application state, and build frontend experiences around the practical requirements of a financial product.

Implementation

Technical breakdown.

All three applications use Next.js, React, TypeScript, and Tailwind CSS, but their frontend architectures reflect different requirements.

The merchant application prioritizes multi-tenant authentication, permissions, complex forms, and server-state management.

The admin application emphasizes operational dashboards, filtered data, sensitive mutations, and clear error recovery.

The checkout application uses a smaller, focused state model to manage a single asynchronous payment lifecycle.

  1. Multi-Application Frontend Architecture

    • Next.js
    • React
    • TypeScript
    • Tailwind CSS
    • Base UI

    The applications were organized into separate repositories rather than one monorepo.

    Each application maintains its own routing, feature modules, dependencies, UI infrastructure, and backend integration layer.

    Within the merchant and admin projects, I used feature-oriented organization to group related components, data hooks, actions, validation schemas, and utilities.

    This provided clear boundaries between areas such as authentication, transactions, onboarding, team management, and financial operations.

    • Next.js App Router with Server and Client Components.

    • Feature-specific modules for complex application workflows.

    • Reusable table, dialog, form, navigation, and feedback components.

    • Server-side integration boundaries for authenticated API requests.

    • Responsive interfaces for desktop and smaller screens.

  2. Authentication, Authorization, and Organization-Aware State

    • Next.js Server Actions
    • TanStack Query
    • TypeScript
    • Zod
    • REST APIs

    Merchant and admin functionality required protected access to backend resources.

    I implemented frontend session handling around the backend's authentication APIs, keeping bearer credentials inside server-managed HTTP-only cookies.

    For merchant accounts, the application also needed to support multiple organizations and different team permissions.

    An important distinction was separating a confirmed authentication failure from a temporary service outage.

    When identity verification is temporarily unavailable, the application can present a retryable state rather than automatically treating the session as invalid.

    • Server-side identity verification for protected layouts.

    • Organization membership validation before switching accounts.

    • Role and permission checks in sensitive frontend actions.

    • Organization-scoped TanStack Query keys.

    • Cache separation when switching organizations.

    • Revalidation of access before protected mutations.

    • Explicit handling of expired sessions and temporary authentication-service failures.

  3. API Integration and Runtime Data Validation

    • TypeScript
    • Zod
    • TanStack Query
    • REST APIs

    The applications integrate with an existing FastAPI backend.

    I implemented frontend API clients and action layers that translate backend responses into the data structures required by each interface.

    In the merchant and admin applications, runtime Zod schemas validate important responses rather than relying exclusively on TypeScript compile-time types.

    This was particularly important where backend endpoints returned different response structures or did not provide complete pagination metadata.

    For example, some lists use an additional-record request to determine whether another page exists without displaying an invented total.

    • Centralized server-side API request utilities.

    • Structured success and error handling.

    • Runtime response validation.

    • Typed action results for frontend mutations.

    • Consistent loading, empty, error, and retry states.

    • Data refresh and cache invalidation after updates.

    • Explicit handling of unavailable API capabilities.

  4. Payment Lifecycle and Checkout State Management

    • Next.js
    • React
    • TypeScript
    • Tailwind CSS
    • REST APIs

    The checkout application introduced challenges that differed from traditional dashboard development.

    Payment sessions are asynchronous, amounts must be displayed accurately, and the customer's device clock cannot be treated as authoritative.

    I implemented a focused React state model to handle these requirements.

    The checkout uses native React state and fetch-based API helpers rather than introducing TanStack Query or a form library where the narrower workflow does not require them.

    • Parsing and validating incoming payment parameters.

    • Preventing duplicate payment initialization from repeated React effects.

    • Polling for backend payment status updates.

    • Preventing stale responses from replacing terminal payment states.

    • Normalizing monetary values using integer kobo representations.

    • Displaying partial payments and remaining balances.

    • Calculating countdowns using server-provided time and expiry values.

    • Separating pending, successful, cancelled, failed, and expired states.

    • Validating payment return URLs and handling support navigation.

  5. Financial Operations and Safe Frontend Mutations

    • Next.js Server Actions
    • TanStack Query
    • React Hook Form
    • Zod
    • REST APIs

    The administrative application required additional safeguards because certain actions affect financial or operational records.

    I implemented confirmation and validation flows designed to reduce avoidable mistakes and ambiguous outcomes.

    These are frontend-level safeguards around existing backend operations. They do not replace backend authorization, financial controls, or transaction atomicity.

    • Re-fetching current records before sensitive actions.

    • Comparing financial details with the values originally reviewed.

    • Blocking submission when records have changed unexpectedly.

    • Validating transaction identifiers and permitted actions.

    • Processing selected transfer decisions sequentially.

    • Reporting partial success or failure for multi-record actions.

    • Preventing blind retries when an API response does not establish whether an operation completed.

    • Refreshing related financial views after mutations.

    • Sending only modified fields when editing SIM records to avoid overwriting independently updated values.

  6. Operational Data Visualization and Reusable Interfaces

    • React
    • Next.js
    • TanStack Query
    • Recharts
    • Tailwind CSS
    • Base UI

    The merchant and admin applications required many related interfaces for viewing and managing structured data.

    I developed reusable components and patterns for dashboards, tables, filters, confirmation dialogs, and forms.

    In the administrative application, operational filters are represented in URL parameters so views can retain their filtering context when reloaded or shared.

    The application also uses server-side query prefetching and hydration to coordinate initial data loading with client-side updates.

    • Responsive dashboard layouts and navigation.

    • Filterable and paginated transaction tables.

    • URL-driven query parameters.

    • Independent loading and failure states for dashboard panels.

    • Server-prefetched TanStack Query data.

    • Reusable validation and confirmation components.

    • Recharts visualizations for operational breakdowns.

Outcomes

What the work delivered.

My work delivered the frontend implementation for three distinct parts of Airbenda's product ecosystem, connecting merchant operations, administrative workflows, and customer checkout to the existing backend.

The strongest documented results are the implemented applications, their supported workflows, and the engineering safeguards incorporated into their interfaces.

The implementation is documented across the three frontend codebases and their development histories.

No independently verified figures for transaction volume, user adoption, conversion improvements, revenue, or operational time savings are available from the inspected source.

Some product capabilities remain dependent on backend contracts or deployment-specific configuration and should not be presented as fully operational without confirmation.

  1. Deliverable

    Three Independently Developed Frontend Applications

    Implemented the merchant application, internal administrative console, and hosted checkout as separate Next.js projects.

    Together, they cover business onboarding, payment operations, internal review, and customer-facing payment experiences.

  2. Deliverable

    Comprehensive Merchant Management Interfaces

    Built the merchant frontend for account onboarding, transaction monitoring, payouts, payment links, team management, and business settings.

    The application supports different organization roles and permission-sensitive workflows.

  3. Deliverable

    Internal Operations and Financial Review Tools

    Developed an administrative console with protected operational dashboards, transaction review, verification interfaces, payout tracking, receiving SIM inventory, and financial journal presentation.

    The implementation includes frontend confirmation and validation safeguards for sensitive actions.

  4. Deliverable

    Asynchronous Airtime Checkout Experience

    Built a hosted checkout with validated payment entry, payment-status polling, server-aligned countdowns, partial-payment handling, and explicit success and recovery states.

    The frontend relies on backend-confirmed payment outcomes rather than assuming settlement.

  5. Deliverable

    Maintainable Integration and State Management

    Implemented typed API boundaries, runtime validation where appropriate, organization-scoped caching, reusable components, and consistent data-refresh strategies.

    These provide a maintainable frontend foundation for continuing development as the platform evolves.