Ajiteru DolapoAjiteru Dolapo

Precium (formerly Revio Pay)

Designing a Unified Payment Platform for Emerging Markets

About

  • Live link: Check out the product here.
  • Role: Product Designer
  • Company: Effects Studios (contracted by Precium)
  • Tools: Figma, Figjam, Storybook, MUI (Material UI)
  • Skills UX Research, UI Design, Design Systems, User Flow Mapping, Prototyping, Component Design

Metrics

$5.2M seed raise led by QED Investors and Partech.

Introduction

How do you make online payments feel simple for businesses navigating the complexity, fragmentation, and uncertainty of emerging markets?

A business owner trying to accept recurring payments faces a specific gauntlet: integrating multiple payment gateways, hand-building billing logic, deciphering inconsistent payment failure codes, and watching revenue leak through failed transactions every month with no tools to recover it. Merchants across Africa and other emerging economies are moving online fast, but the infrastructure hasn't kept pace.

Precium was founded in 2020 on the thesis that "there is more to getting paid than simply processing payments." When Effects Studios was brought in to design the new Precium platform, the stakes were real, VC-backed, under a tight delivery timeline, serving hundreds of merchants across 25+ countries. The design question was: how do you take something this complex and make it feel manageable for the businesses depending on it?

Overview

The Problem

Merchants in emerging markets face three compounding problems. Payment orchestration is expensive and brittle, managing Flutterwave, Paystack, card networks, and debit orders through separate integrations with no unified layer. Recurring billing is either non-existent or forces merchants to hire developers for custom solutions. And failed payments go unrecovered, no retry logic, no dunning, no standardized error reporting, just silent churn.

Global merchants are often dogged by reconciliation nightmares, and inconsistent, unclear, and unresolvable payment failures leading to involuntary churn and sales losses.

Target Users

Precium's primary user is the merchant, specifically profitable scale-ups and medium-sized businesses with a yearly TPV of at least 1M Rands (~$58,939) that are most likely to accept recurring payments. A secondary user group is developers who integrate Precium into their systems via API.

Solution

The Precium Web Application (Alpha 0.01) covers the full lifecycle of getting paid online: a merchant dashboard for revenue visibility and KPI monitoring, guided KYC, a checkout experience with hosted invoice and payment pages, customer management with payment history and collection analytics, developer tools for API key and webhook management, and team management with role-based access control.

Project Goals

The platform needed to get merchants live in as little as 24 hours after onboarding, reduce involuntary churn through better payment failure visibility, support expansion into new markets with multi-currency and multi-gateway architecture, and scale from no-code to high-code integration patterns without forcing merchants into a single pattern.

Research

Market Landscape

More merchants are selling online across emerging markets, and gateway solutions like Paystack and Flutterwave handle one-off transactions reasonably well. But the moment a merchant needs recurring billing, subscriptions, installment plans, debit orders — existing solutions fall short. At the same time, rising inflation and lower real consumer incomes are making predictable recurring revenue more important, while consumer financial stress means failed payments are increasing. Merchants need tools to recover that revenue automatically, not chase it manually.

User Pain Points

Four core pain points drove the design brief:

Intergration complexity — Merchants must engage custom dev work or accept gateway limitations. There's no no-code or low-code option for complex billing needs.

Reconcilliation hell — Multi-gateway operations mean no single source of truth, making reconciliation a manual nightmare.

Involuntary churn — Failed payments that aren't retried or communicated result in silent subscriber loss that merchants often don't detect until it shows up in revenue.

Global expansion friction — Expanding into a new market means a new gateway integration, new compliance requirements, and new currency handling, all done by hand.

Competitive Context

CapabilityPaystack / FlutterwavePrecium
One-off paymentsStrongStrong
Recurring billing managementBasicCore feature
Payment orchestration (multi-gateway)NoneCore feature
Revenue recovery / dunningNoneRoadmap
Emerging market localizationPartialCore focus
Merchant dashboard analyticsBasicDeep

Key Insight

The most clarifying thing from research was what I started calling the maturity ladder: merchants don't all want the same level of control. Some want to start immediately with no code. Others want deep API access. Precium needed to serve both ends of that spectrum without forcing merchants into a single integration pattern. This shaped the IA and the onboarding flow more than anything else.

Ideation

Onboarding Model: Sales-Led vs. Product-Led

A product-led approach (self-serve sign-up) would maximize reach and reduce CAC. But for a VC-backed startup operating across 25+ countries with real compliance surface area, quality control mattered more than volume in the early stages. We aligned on a sales-led approach for Alpha: merchants contact sales via a form, get vetted, and receive a curated onboarding experience. This gave Precium control over early merchant access, reduced compliance risk, and kept the team in close contact with their first cohort. Product-led onboarding was explicitly parked for a future version. The architecture would support it, but we weren't building it yet.

Dashboard Information Architecture

The core tension was between surfacing the numbers merchants care about (revenue, subscribers, TPV) and surfacing what needs attention (failed payments, overdue invoices). After mapping merchant mental models — they think "how am I doing?" before "what do I need to do?" — we landed on a KPI-first dashboard. Revenue is the hero; the feeds table is the diagnostic.

Checkout Architecture

We explored embedding checkout inside the merchant's own site (lowest friction, highest PCI scope), redirecting to Flutterwave or Paystack directly (limited branding control), and a Precium-hosted page with merchant branding. The hosted page won: it kept PCI scope manageable for Alpha, gave Precium control over the UX, and delivered consistent branded experiences across all merchants.

Design System: Custom vs. MUI

We mapped our Figma design system directly into code by customizing Material UI with our tokens (color, typography, spacing), which gave us speed without breaking consistency.

The visual direction was a deliberate shift, away from “trendy and playful” toward something more stable and trustworthy, which better fits a payments product.

We chose MUI over building a custom design system because it offered faster delivery, accessible defaults, and proven interaction patterns. We layered our brand through theming instead of rebuilding primitives.

Storybook was used to document components and keep design and engineering aligned.

Design Process

Wireframing & Direction

The engagement opened with wireframing core workflows and establishing design direction. In Figma we mapped the full IA. Structural decisions here includes: breadcrumb navigation for deep pages, and the test/live mode toggle in the header.

Moodboard, Branding & Component Setup

I designed the component library in Figma and collaborated with developers to build it on Storybook. Color system, typography scale, spacing, and core components — buttons, inputs, tables, modals, form fields . This phase also produced the first hi-fidelity mockups of the dashboard and checkout pages, shown to internal stakeholders before we moved into feature work.

With the groundwork fully established, I moved on to designing the features.

Early Design Decisions

Sales-Led Onboarding to Protect Early Quality

The sales form collects business details, trading volume, and industry, giving Precium enough context to vet merchants properly. Acceptance and rejection email templates ensured consistent communication throughout. The trade-off is slower growth; the benefit is better-fit merchants and lower churn in the early cohort.

Test/Live Mode Split for Safe Exploration

Every merchant starts in Test mode with demo data visible across all dashboard sections. This lets them explore the full platform before committing to going live. Live mode unlocks only after all KYC sections are verified.

Progressive KYC to Reduce Drop-Off

The KYC form started as a long form. After mapping how merchants actually have documents — in pieces, from different sources, often weeks apart — we restructured it as a four-section progressive form (Business Details, Account Owner, Bank Account, Gateway & Payment Methods) that could be filled out of sequence and saved in draft, with a persistent progress indicator. Hubspot report 86% higher conversion rates for multi-step forms.

Privacy-First Checkout with Code Unlock

Invoice URLs are shareable links, which means they can reach unintended viewers. Invoice data contains sensitive customer information.

The invoice privacy model changed entirely after we flagged an early design that exposed all customer data to anyone with the URL, we redesigned checkout to mask all data by default for unauthenticated viewers, with a one-time privacy code unlock delivered to the invoice recipient's registered email. Customer data stays protected without adding friction for legitimate recipients.

Role-Based Access at Page-Level Granularity

Enterprise merchants have teams, and not everyone should see everything. Each role has a permission level, Read, Write, or Both, for every page in the platform. A billing manager shouldn't see developer API keys; a support agent shouldn't approve invoices.

Navigation

Navigation is grouped into clear sections, making it easier to control what each team member can see, with a Test/Live switcher at the top for quick access.

Core Flows

Merchant Onboarding

The merchant journey starts on the Precium website. The sales form collects business information. After review and acceptance, merchants receive an email that doubles as email verification, clicking it opens the password setup flow.

Sales led onboarding

Product-led onboarding

Get Started

New merchants land in a test environment with demo data pre-populated. Merchants must complete and submit the KYC form. Submissions are reviewed, and merchants receive email reminders and in-app notifications about their KYC status. Once approved, merchants can go live.

Overview

High-level overview designed to give merchants quick, actionable snapshot of business performance, highlighting key metrics, trends, and potential issues across revenue, payments, and customer activity.

Invoice Feed

Feed allows merchant track, manage and carry out invoice-related actions such as refunds & disputes.

Feeds

Issuing a refund

Accepting a dispute

Rejecting a dispute

Customer Management

A centralized table for viewing and managing all customers across brands, with bulk import to efficiently create or update records at scale.

Invoicing

Merchants can create and manage invoices for their customers.

Creating an invoice

Unlocking an invoice

Customer receives an invoice email with a CTA to view the invoice. The URL shows masked data by default. Clicking "Unlock Invoice" sends a one-time code to unlock the invoice to the recipients email; after entry, the invoice is visible for the session.

Checkout Page

The checkout page is dynamic. For speed, merchants can send invoices without line items, enabling a simple single-panel checkout. For more detailed use cases, invoices can include line items, activating a split-panel layout.

Offering multiple payment methods is critical, users expect choice, and limiting options hurts conversion. In fact, 11% of users abandon checkout when their preferred method isn’t available (Baymard Institute, 2023), making clear, well-structured payment selection essential.

API Keys & Webhooks

Designed for managing integration access and event handling. API Keys allow merchants to create and control keys across environments, while Webhooks enable configuration of event notifications and callback endpoints.

Creating an API key

Creating a webhook

Testing a webhook

Teams & Roles

Merchants can invite and manage team members, assign roles, and control access across their organization.

Inviting a team member

Creating a new role

Account

Account gives merchants a centralized place to control their business details, communication preferences, and overall account configuration.

Reflection

KYC Is a UX Problem

Going in, I underestimated how much friction KYC would create. In regulated emerging markets, merchant verification requires substantial documentation, multiple uploads, authorized signatory processes, shareholder disclosures. A business owner might know their banking details immediately but need to request their registration certificate from a lawyer. Designing the KYC form as a progressive, out-of-sequence multi-section form with draft saving and clear progress tracking made the process feel manageable instead of monolithic.

Design System Investment Compounds

Spending heavily on the MUI component library and Storybook documentation before feature work felt risky in the moment, weeks that could have been screen designs. In retrospect it was the highest-leverage decision of the project.

Sales-Led Onboarding Is a Double-Edged Sword

The sales-led approach gave Revio control over merchant quality early and kept the compliance surface manageable. But merchants who found Revio online couldn't immediately try the product — "Get Started" led to a form, not a sandbox, and potential customers had to wait for human review before experiencing anything. That's the right trade-off for an early-traction regulated payments company. But in the next iteration I'd push for a sandboxed self-serve experience early where prospective merchants can explore the dashboard with demo data before committing to the sales form. It removes the evaluation barrier without opening compliance risk.

What I'd Do Differently

We built from real data and stakeholder insight, not assumptions. However, for the new build and features introduced at Alpha, I would have prioritized instrumentation earlier. Feature flags, heatmaps, and session recordings would enable continuous validation through real user behavior. Although product analytics was scoped as future work in the PRD, I would have pushed to move it forward to establish faster feedback loops.

Credits

The Effectstudios Team, alongside the Precium Engineering and Product Team and the Chief Product Officer, collaborated to define the product direction, design the experience, and build the platform end-to-end.