← All work Fintech · Web Platform · Internal Tool

Pecto — Corporate Prepaid Cards

An admin and cardholder web platform for issuing, approving, and managing corporate prepaid cards — designed for finance teams who needed speed and auditability more than decoration.

ClientComviva
My roleProduct Designer
PlatformWeb (desktop-first)
StatusShelved post-prototype
Pecto approvals dashboard
Context

Pecto was Comviva's answer to a very unglamorous but very real problem: companies issuing prepaid cards to employees — for reimbursements, travel, or vendor payments — had no clean way to manage the whole lifecycle in one place. Finance admins were approving transactions, tracking e-money inventory, and fielding cardholder questions across disconnected tools.

I joined as the design partner working alongside project managers and developers, translating a fairly complex back-office workflow into something an admin could actually use without a training manual. The project reached working prototype stage before Comviva de-prioritized it in favor of other roadmap items — it never shipped to production, but the design work is a fair representation of how I approach a dense, workflow-heavy B2B problem.

Problem

The brief centered on one objective: create a system for a prepaid card program that could handle three very different users on one platform — the finance admin approving transactions, the cardholder checking their balance, and the customer-care agent resolving disputes. Each needed a different view of the same underlying data, without the platform turning into three disconnected products.

  • Admins needed to approve or reject transfers quickly, across multiple banks, without losing context
  • Cardholders needed self-service — add a card, check balance, dispute a charge — without calling support for everything
  • The whole system needed a clear audit trail, since it was handling real money movement
Process

I worked closely with project managers and developers from day one — empathizing with admin and cardholder pain points, then brainstorming toward a structure that could scale. Before touching visual design, I mapped the core flows as click-through diagrams: how a mobile number becomes a customer-care lookup, how a transaction moves from pending to approved or rejected, and how "Flow 1" (card issuance) connects into everyday servicing.

That flow-mapping stage mattered more than usual here — a prepaid card platform lives or dies on whether the edge cases (a rejected transfer, a disputed charge, a locked card) are as clear as the happy path.

Mapping the flows
Pecto user flow diagrams for onboarding and customer care
Design decisions

A left-rail structure with three top-level areas — E-money Inventory, Approvals, and My Activity — kept the admin's mental model simple: everything is either money you're tracking, money you're approving, or a log of what you've already done.

Approvals were designed for scan-and-decide speed. Bank name, mode of transaction, currency, amount, and date sit in a single scannable row, with Approve and Reject as the only two primary actions — colored distinctly (green/orange) so an admin working through a long queue never has to second-guess which button does what.

The cardholder side (MCIP) borrowed the same visual language but flipped the priority: balance and card status up front, transaction history one tap away, and a profile view that doubles as the customer-care agent's lookup screen — one component, two audiences.

Cardholder & customer-care views
MCIP login and cardholder profile screens
Transaction & dispute management
Pecto card details and transaction history screen
Outcome & learnings

Pecto didn't ship — Comviva shelved the program before it reached production — but the prototype held up well internally as a reference for how to structure a multi-role fintech admin tool. The clearest lesson was about scope: B2B financial tools succeed or fail on how well they handle the 20% of flows that aren't the happy path, and that's where most of the design time actually went.

It's also a reminder that not every well-designed product gets to launch, and that's a normal part of working inside a large product org — priorities shift, and the design work still has to be sound regardless of what happens after handoff.

Pecto was shelved before launch, so there's no post-launch usage data to report here — this case study focuses on process and screens rather than impact metrics.