Cash Deposit: Turning a 28-Hour Repayment Process Into a 7-Minute Task

Context

Jiva runs on credit. Sahabat Jivas (SJs) receive credit advances to procure corn, order inputs, or support farmers. That credit comes back either as a corn truck or a cash repayment.

Cash repayment was the slow path, and it was entirely offline. An SJ repaying would travel to a bank, deposit the exact amount using a static Virtual Account number they'd memorised or written down, collect a paper receipt, photograph it, and upload it as proof. Finance then verified it manually and updated the ledger by hand.

Every step was a failure point users forgot the VA number, receipts got uploaded wrong, manual reconciliation introduced delays and because the whole thing required a physical bank visit, it only worked during banking hours, in areas with bank access.

The interest cost of slow repayment sat entirely with Jiva. SJs paid no interest on credit; Jiva did, to its banking partners. Every extra day of outstanding credit was a cost Jiva absorbed, with no pressure on the user to move faster. Manageable at the scale Jiva was at. Not manageable at the scale Jiva was heading toward.

The problem

This wasn't broken because of poor design, it had simply never been designed. It was a manual workaround that had calcified into standard operating procedure.

As Jiva grew, more SJs meant more manual reconciliation, more receipts to verify, more errors to chase. SJs in remote areas had limited banking hours and branch access. When deposits took hours to confirm, users had no visibility into whether payment had landed, so they called their AC, who called the MC, who chased Finance — the same chain that had buckled under the dispatch flow, buckling again here.

The question wasn't whether to change this. It was whether users and internal teams could be brought along with the change.

What success looked like

• For SJs: complete a deposit from their phone in minutes, with clear confirmation it was received. No bank visit, no receipt upload, no waiting.
• For Finance: real-time visibility into incoming payments, without manual verification.
• For Jiva: faster cash rotation, directly reducing interest cost and improving how quickly credit could be redeployed.

Key Decisions

What stayed the same. Before anything changed, SJs selected which farmers had repaid and how much, each repayment tagged against the correct farmer's credit record. Getting this wrong had real financial consequences downstream. The payment method changed; this requirement didn't, so we left it alone.

Dynamic Virtual Account numbers: The old flow used one static VA number, memorised and reused. The new one generated a unique VA per transaction, expiring in 3 hours, a security and reconciliation requirement, since a unique VA per payment meant automatic matching with no manual intervention. But it created a real design problem: users were used to one number that never changed, and now had a 3-hour window where getting it wrong meant an expired payment.

The fix was making stakes explicit in plain language:

Not copywriting, a design decision that prevented financial errors in a high-stakes flow.

And for expired payments:

The copy was doing as much design work as the layout.

Designing for fear, not just confusion:

Usability testing showed users weren't confused by the interface, they were scared of it. Moving from a bank visit to an in-app digital payment wasn't a small UX change for this population; it was a new financial behaviour entirely. Three anxieties surfaced repeatedly: the changing VA number felt untrustworthy, "Virtual Account" was an unfamiliar term, and users assumed they still needed a bank visit. We addressed all three before a user reached the payment screen, including a sub-minute explainer video made with Brand and Comms, distributed via WhatsApp by ACs before launch.

The video data confirmed it worked: 69% of views came from returning users watching multiple times while completing their first payment, and 70% of traffic came from WhatsApp, meaning ACs were proactively sharing it.

☝🏽

Change management spread through the same social infrastructure the old broken process had relied on.

The Retool dashboard: The SJ-facing flow was only half the change. Finance had manually processed receipts for years; with Xendit, payments confirmed automatically, but Finance needed a new tool to monitor status, handle exceptions, and manage disputes. I designed this alongside the user-facing flow, deliberately, since what the SJ saw in-app had to match what Finance saw in real time.

Edge cases (late payments, status mismatches, under/over-payments) each needed a user-facing state and an internal resolution path. Designing only one side would have created gaps users eventually fell through.

Getting the organisation across the line

A project touching banking infrastructure, user financial behaviour, internal operations, and engineering simultaneously needed organisational confidence before it could ship, this wasn't a small internal sign-off, it was leadership agreeing to change how money moved through the business.

I presented the feature in a pod meeting with the CEO present. The goal wasn't to walk through screens, it was to make leadership certain enough to greenlight the change. The CTO noted afterward that the presentation gave the organisation the confidence it needed to move forward.

Getting that buy-in meant understanding what each stakeholder needed to feel certain about, and structuring the communication around those specific needs. That's design work, even when it doesn't happen in Figma.

Outcomes

• 28 hours became 7 minutes. Not a marginal improvement, a process transformation. The bank visit, the manual receipt upload, the manual reconciliation, the banking-hours dependency: gone.
• The onboarding video did its job. 69% of views from returning users, 70% of traffic from WhatsApp, unprompted, ACs shared it because it was genuinely useful.
• Finance got their time back. Manual receipt verification was eliminated for standard payments; the team shifted from processing uploads to handling genuine exceptions, a fraction of the previous volume.
• Cash rotation dropped from 14 to 10 days the following month, alongside a separately introduced penalty policy and a parallel redesign of the Total Outstanding screen. All three moved in the same window; none can honestly claim sole credit for the shift.
• What we couldn't fully measure. We tracked adoption directionally, not formally. We know from testing the fear was real, but we don't have a clean before/after on how many users who'd avoided cash deposits started using the new flow, that would've been the most meaningful validation, and we should have instrumented it before shipping.

What I learned

• Designing for behaviour change means designing the transition, not just the destination. The video, the first-time screen, the explicit VA copy, none of these were features. They were the transition layer between what users knew and what we were asking them to do. Easy to skip when focused on shipping; on this project, it was load-bearing.
• Precise language is a design tool, not a copywriting flourish. The exact wording on the payment deadline prevented real financial errors. Generic fintech copy in that screen would have caused real harm.
• The internal tool is part of the service. The Retool dashboard wasn't a side task, the SJ-facing flow and the Finance tool were one system.
• Organisational alignment is design work. Getting leadership confident enough to ship a change this significant required the same clarity of thought as the interface itself.