03 / 15Financial systems / SuperpageSuperpage portfolio

FinTech Multi-Tenant SaaS Systems Design

Multi-tenant payments

For Superpage, I designed a payment system that accepts money through one checkout, preserves vendor ownership, applies platform fees, selects a gateway route, and keeps settlements traceable from end to end.

Company

Superpage — Creator commerce platform

My Role

Founder · Lead Product Designer

Project

Payments · Vendor routing · Settlements

Methods

Service blueprint · Wireflows · State modelling · Prototyping

Platforms

Web checkout · Vendor dashboard · Admin operations

Multi-tenant payments — product overview — Multi-tenant payments / Selected product view

Unified customer checkout

Perspectives designed end-to-end

Primary and fallback routes

Full flow

Checkout-to-payout states mapped

Problem

One customer checkout had to route money accurately across multiple creator vendors.

Ownership

Service blueprint, wireflows, state modelling, prototyping, and operational UX.

Constraints

Model failures, fallback routes, fees, and settlements across customer, vendor, and admin views.

Outcome

A traceable checkout-to-payout system unifying all three operational perspectives.

The Brief

Superpage helped creators publish storefronts and sell digital products directly to their audiences. Once multiple creators could receive payments through the same platform, a simple checkout became a multi-tenant money movement problem.

Every purchase had to remain connected to the correct vendor, fee agreement, gateway route, refund history, and settlement record—without exposing that complexity to the customer.

One checkout for the customer. Clear ownership for every payment behind it.

I led the product design across three connected perspectives: the customer completing payment, the vendor tracking earnings, and the Superpage operator resolving gateway failures and settlement issues.

My mandate: define a shared payment model, map the critical edge cases, and turn the system into testable wireflows before visual design or engineering implementation.

Low-fidelity wireflow showing a Superpage customer checkout, payment intent, routing decision and vendor payout — **Core Payment Wireflow** · Customer intent, tenant ownership, route selection, and vendor payout mapped before interface styling

Problems Identified

⌁

Hidden Ownership

A transaction could not be treated as a platform-level payment. Vendor identity had to survive every gateway and settlement event.

↗

Gateway Failure

A failed primary route needed a safe fallback without creating a duplicate payment or losing the original transaction identity.

Variable Fee Rules

Each vendor could have different platform fees and payout terms, making fee visibility and calculation a core product concern.

◷

Settlement Opacity

Vendors needed to understand what was collected, what was deducted, what was pending, and when a payout would arrive.

Unclear Exceptions

Pending, failed, refunded, and blocked states required different explanations and next actions for vendors and operators.

＋

Tenant Scale

New vendors needed reusable configuration patterns instead of a custom operational process for every account.

Design Process

Map the Money Movement

Started with a service blueprint that followed one payment from checkout to vendor settlement. Mapped system events, ownership changes, gateway responses, fee calculation, refunds, and operator interventions.

Service BlueprintPayment LifecycleEdge Cases

Define a Shared State Model

Aligned customer-facing language, vendor status, admin status, and backend events around one state matrix: initiated, pending, paid, failed, refunded, blocked, and settled.

State MatrixContent DesignSystem Events

Wireframe Three Perspectives

Built low-fidelity wireflows for customer checkout, vendor earnings, and Superpage operations. Keeping the work intentionally rough helped the team debate logic and hierarchy before visual polish.

Balsamiq-style WireframesWireflowsInformation Hierarchy

Design the Exception Paths

Worked through gateway timeouts, fallback routing, incomplete vendor setup, partial refunds, payout holds, and reconciliation mismatches. Each state had to explain what happened and what could happen next.

Failure ModesFallback LogicRecovery UX

Validate with Engineering

Reviewed wireflows against gateway behaviour and backend events, resolved ambiguous states, and annotated the expected data and actions for each surface before handoff.

Engineering ReviewFlow AnnotationsHandoff

Low-fidelity Superpage payment operations dashboard wireframe — **Admin Overview** · Transaction health, gateway status, settlement queue, and exceptions in one operational surface

Low-fidelity Superpage vendor payment configuration and settlement wireframe — **Vendor Workspace** · Routing configuration, fee rules, payout maths, and transaction history

Low-fidelity wireframes for paid, pending, failed, refunded, settlement-ready, and blocked payment states — **State Exploration** · Every status pairs system context with the next useful action

Impact & Outcomes

The wireframes gave Superpage a shared operational model before visual design began. Product and engineering could review the same payment states, ownership rules, and recovery paths without getting distracted by surface styling.

One

Shared Payment Model

Customer, vendor, admin, and backend states were aligned around the same transaction lifecycle.

Clear

Exception Ownership

Failed, pending, blocked, and refunded states explain what happened and who can resolve it.

Scale

Reusable Tenant Setup

Gateway priority, fee rules, and settlement timing became configurable patterns for future vendors.

Key Learnings

Start with money movement, not screens

The service blueprint exposed ownership and settlement questions that a dashboard-first approach would have hidden.

Wireframes keep logic honest

Removing visual polish made every review about hierarchy, system behaviour, missing data, and recovery—not aesthetic preference.

Exceptions are the real payment product

The happy path is short. Trust is built by how clearly the product handles timeouts, refunds, blocked payouts, and reconciliation gaps.

Shared language reduces delivery risk

A single state model gave product, design, and engineering the same meaning for paid, pending, failed, refunded, and settled.

Have something in mind?

Let's make it work.

Ex-Founder, Product Manager & Designer. Based in Dubai.

Email Srivatsa ↗LinkedIn ↗