The financial layer that connected an entire ecosystem.

01 Context

Money moved through seven partners. Nobody saw the whole picture.

02 Problem

No one could say, with confidence, where a payment actually stood.

• — Finance reconciled manually, every morning. Someone downloaded the PayU settlement report and matched it against the bank statement, payment by payment. Rupifi worked the same way. EPay Later arrived by email as a spreadsheet.
• — Mismatches had no real process. Finance had to log into PayU's dashboard, raise a ticket, and chase it through email. No record of any of it lived inside Solv.
• — Support couldn't answer without switching tools. The question came in through our order tool, but the answer was in PayU's dashboard. Ten to fifteen minutes of context-switching before every reply.
• — Sellers had no visibility at all. The app showed delivery status but said nothing about settlement. Most "where's my money" questions escalated straight to account managers.

03 Design process

Six months. Five phases. The textbook order, bent where the project needed it.

Run as Agile sprints across design, product, and engineering.

• 01 Discover Stakeholder interviews, observation sessions, transaction flow mapping
• 02 Define Insight synthesis, problem reframing, design principles, scope alignment
• 03 Ideate Wireframe explorations, data visualisation research, direction validation
• 04 Prototype High-fidelity Figma screens, interactive prototype, executive UAT
• 05 Deliver Annotated handoff, developer collaboration, post-launch tracking via MoEngage

04 Discover

I started with people, not data models.

• — Where she switched tabs (PayU dashboard → Excel → email).
• — Where she paused and double-checked a UTR against the bank statement.
• — Where she gave up and estimated.

Watching someone work around your product teaches you more than any question you can ask them.

One seller's workflow changed how I framed the problem.

Seller journey map

Scroll horizontally →

Three roles, three different versions of "broken".

• Finance team

  More data wasn't the problem. They needed the dashboard to lead with what was wrong: overdue, short-collected, disputed, across the three payment partners. Successful transactions were noise they were tired of scrolling past.

• Support team

  Agents were flipping between two systems to answer every seller question: order details in one tool, payment details in another. Each query cost 10–15 minutes of tab-switching before they could even reply.

• Sellers

  They couldn't see what stage their money was at. Orders moved from delivered → return window → settlement initiated → paid, but the seller never saw any of it. They wanted clarity more than they wanted speed.

05 Define

The brief asked for a drill-down. Discovery said scrap it.

1. 01

   Lead with what needs attention

   The 20% of transactions that are overdue, short, or disputed get the front page. The 80% that are fine sit one click away.

2. 02

   One number, three views

   Finance, support, and the seller are all looking at the same payment. The view changes; the underlying figure doesn't.

3. 03

   Keep the systems in sync

   A status change in finance has to show up in the support tool and the seller app the moment it happens. If the numbers can disagree, they will.

One swimlane, four systems: the map design, PM, and engineering all built against.

The new scope needed something everyone could point at. I mapped the end-to-end order flow as a swimlane across Solv's core systems: Commerce, Seller, OMS, and Finance. That gave design, product, and engineering one shared view of where the money moved and where its status changed.

Every transaction moves through the same states. We mapped them before drawing a screen.

Underneath the order flow, every transaction moved through the same payment lifecycle: success, retries, chargebacks, refunds, across advance and balance payments. I mapped this before designing any screen, so the team could see exactly which state could lead to which.

06 Ideate

Two things were broken: what the screen led with, and how the numbers rendered.

We led with everything. Finance only cared about what was wrong.

Our initial wireframes showed everything at equal weight. Every transaction, every vendor, equal pixel real estate. We took it to a usability test with two finance team members.

"I don't need to see successful payments every morning. I need to see what's overdue." — Finance team member, usability test session

That sentence rebuilt the dashboard. The new version led with what was wrong (overdue, on-time, short-collected) and pushed the rest one click down.

Wireframe V1 vs V2 — flat hierarchy vs status-first architecture with drill-down

₹5,000 and ₹5 crore in the same chart: impossible on a linear scale.

• —PayU card and invoice payments, anywhere from ₹5,000 to ₹50 lakh per transaction
• —Rupifi pay-later settlements
• —EPay Later pay-later settlements
• —Cash-on-delivery batches from the four logistics partners, up to ₹5 crore each

07 Prototype

A senior exec rejected the prototype, until we added Excel back in.

We built a Figma prototype covering the core Finance flows: dashboard, transaction view, UTR approval, payout. Usability testing with finance and internal stakeholders mostly confirmed direction. One session stopped the project in its tracks.

A senior finance executive reviewed the prototype and didn't want to move to the new system. Not because it was broken, but because it was unfamiliar.

We didn't change the design. We added a capability the design was missing.

We added import and export: Excel out for control, Excel back in for bulk updates. The executive adopted the platform. In the next phase, export management became a standalone feature that Operations and CRM actively asked for. A resistance fix turned into a cross-team feature.

Settlement Upload — the Excel bridge that became a cross-team feature

08 Solution

Seven views of the same money, each shaped around a different job.

Five views inside the internal tools, two on the seller side. The underlying numbers are the same in every one; what changes is what gets put in front of you.

Finance — Dashboard

The dashboard leads with what's wrong.

Collection status sits up top: overdue, on-time, short-collected, broken down by each of the three payment partners. The bar charts use a logarithmic scale so a ₹5,000 transaction and a ₹5 crore one are both legible in the same view (a fix that took me a side-quest into IBM's data-viz docs).

Finance — Transaction view

Every transaction, one ledger.

A filterable table of every transaction. Click a transaction ID and the row expands into a timeline of how that payment moved: captured, received, refunded, charged back, reversed. Same states the rest of the system uses. Export to Excel sits in the header for the people who still need it there.

Finance — Bank approvals

Approve a bank transfer with the breakdown visible.

When PayU sends Solv a bank transfer, finance has to confirm the amount matches what's owed. The approval screen shows the transaction-level breakdown side by side with the bank reference. Rejections need a written reason, and the same note becomes the ticket finance raises with PayU when amounts don't line up.

Finance — Seller payouts

What we paid the seller, line by line.

One row per payout: amount, bank reference, status. Expanding the row shows the deductions (commissions, taxes, returns, recoveries), and the breakdown matches exactly what the seller sees in their app. No reconciliation calls about "why is your number different from mine".

Support tool

Payment context inside the support tool.

The full payment lifecycle now lives inside the order view that support agents already had open: payment method, settlement status, bank references. Tab-switching to PayU went away. Reply times that were measured in hours dropped to minutes.

Seller — Settlement status

Sellers see what stage their money is at.

Once an order is delivered, the timeline becomes visible: return window → settlement initiated → settled. Same words finance uses internally, so when a seller calls support, both sides are reading the same screen.

Seller — Payment summary

Net earnings, with the maths shown.

Total payouts, bank reference, commissions, taxes, deductions, recoveries. Every figure ties back to the same row finance is looking at: no parallel spreadsheet, no version-control fight over which number is right.