Multi-tenant
Payments System
For Superpage, we 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.
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.
We 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.
The mandate: define a shared payment model, map the critical edge cases, and turn the system into testable wireflows before visual design or engineering implementation.
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.
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.
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.
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.
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.
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.
Customer, vendor, admin, and backend states were aligned around the same transaction lifecycle.
Failed, pending, blocked, and refunded states explain what happened and who can resolve it.
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.
Your project next
Let's build something worth remembering.
Tell us what you're building and we'll come back with a plan, a timeline, and a price.