Cash Deposit x Xendit: From 28 hours to 7 minutes

Context

Jiva runs on credit. SJs receive credit advances to procure corn, order inputs, or support farmers. That credit needs to come back, either as a corn truck or as a cash repayment.

Cash repayment was the slower path, and it was entirely offline. An SJ who needed to repay would travel to a bank, deposit the exact amount into Jiva's account using a static Virtual Account number they had memorised or written down, collect the physical receipt, photograph it, and upload it to the app as proof. The finance team would then verify it manually and update the ledger.

Every step was a potential failure point. Users forgot the VA number and called their division head. Receipts were uploaded incorrectly. Manual reconciliation introduced delays. And because the whole thing required a physical bank visit, it was only possible 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. At current scale that was manageable. At the scale Jiva was heading toward, it was not.

The team:

Product Designer: Sai Shinde

The problem

The cash deposit process was not broken because of poor design. It had simply never been designed. It was a manual workaround that had become 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 limited branch access. When deposits took hours to confirm, users had no visibility into whether their payment had been received, so they called their AC, who called the MC, who chased the finance team. The same human chain we had seen buckle under the dispatch flow was buckling here too. The question was not 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 cash deposit from their phone in minutes, with clear confirmation the payment had been received. No bank visit, no receipt upload, no waiting.
For the Finance team: 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.

What we designed and why

What stayed the same and why

Before anything changed, SJs selected which farmers had repaid them and how much. Each repayment needed to be tagged against the correct farmer's credit record with Jiva, getting this wrong had downstream financial consequences for both the SJ and the farmer. This step stayed in both the old and new flow. Changing the payment method did not change that requirement, and we did not touch what did not need fixing.

Dynamic Virtual Account numbers

After the farmer attribution step, the old flow sent users to a bank. The new one generated a unique Virtual Account number on the spot, specific to that transaction, that amount, and expiring in 3 hours.

This was a security requirement and a finance reconciliation requirement. A unique VA per payment meant every transaction could be automatically matched without manual intervention. But it created an immediate design problem. Users had one VA number they had memorised or written down and used repeatedly. A new number every time with a 3-hour window was a fundamentally different behaviour. Get it wrong and a payment could expire mid-transfer.

The design decision was to make the stakes explicit and the action unambiguous:

⚠️

"Pay Rp5.000.000 before 16 May 2023, 2:59PM to avoid automatic cancellation."

And for expired payments:

🚨

"Your payment link has expired. Please create a new payment and pay within 24 hours."

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

A smallholder farmer walks our researcher through how he navigates the app — in his own home, on his own terms.

Research sessions happened wherever made sense: floors, fields, storage rooms full of harvest. We came to them, not the other way around.

Designing for fear, not just confusion

Usability testing made one thing clear early: users were not confused by the interface. They were scared of it. Moving from a physical bank visit to an in-app digital payment was not a small UX change for this population, it was a new financial behaviour entirely. Three anxieties came out of testing consistently: the VA number changing every time felt untrustworthy, the term "Virtual Account" was unfamiliar, and users assumed they still needed to visit a bank. We addressed all three before a user ever reached the payment screen. First-time users saw an explainer that covered each anxiety directly. We also worked with Brand and Comms to produce a short video, under a minute, walking through the new flow in plain language. ACs distributed it via WhatsApp before the feature launched, so users had seen it before they encountered the new screen for the first time. The video data confirmed the approach was working. 69% of views came from returning users, people watching it multiple times while completing their first payment. 70% of traffic came from WhatsApp, meaning ACs were proactively sharing it. The change management was spreading through the same social infrastructure the old broken process had relied on.

The Retool dashboard

The SJ-facing flow was only half of the service change. The finance team had been manually processing uploaded receipts for years. With Xendit, incoming payments were confirmed automatically, but the team needed a new tool to monitor payment status, handle exceptions, and manage disputes.

I designed the internal Retool dashboard alongside the user-facing flow. The two had to work together: what the SJ saw in the app needed to match what the finance team saw on their end, in real time. Edge cases, payments made after expiry, status mismatches between Xendit and Jiva's system, under and over-payments, each required both a user-facing state and an internal resolution path. Designing only one side would have created gaps the user would eventually fall 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. I presented the feature in a pod meeting with the CEO present. The goal was not to show screens, it was to make leadership feel certain enough to greenlight a fundamental change to how money moved through the business. The CTO noted afterwards that the presentation gave the organisation the confidence it needed to move forward.

Getting that buy-in required understanding what each stakeholder needed to feel certain about, and structuring the communication of the work around those needs. That is design work too, even if it does not happen in Figma.

Outcomes

28 hours became 7 minutes. Not a marginal improvement, a process transformation. The physical bank visit, the manual receipt upload, the manual reconciliation, the banking hours dependency, all of it gone.
Cash rotation dropped from 14 days to 10 days. This project was the larger driver of that improvement. The outstanding balance visibility work done in parallel contributed, but removing the biggest bottleneck in the repayment cycle is what moved the metric.
The video onboarding did its job. Returning users accounted for 69% of video views. Users were watching it repeatedly while making their first payment — exactly what it was designed for. ACs sharing it via WhatsApp was not planned. It happened because the content was genuinely useful.
The finance team 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.
What we could not fully measure. We tracked adoption directionally but not formally. We know from testing that the fear was real. We do not have a clean before and after on how many users who previously avoided cash deposits started using the new flow. That would have been the most meaningful validation and we should have set it up before we shipped.

What I learned

Designing for behaviour change means designing the transition, not just the destination. The new flow was well-designed. But shipping it without addressing the fear users had of a new financial behaviour would have undermined everything. The video, the first-time screen, the explicit copy around the dynamic VA, none of those were features. They were the transition layer between what users knew and what we were asking them to do. That layer is easy to skip when you are focused on shipping. On this project it was load-bearing.
Precise language is a design tool. "Pay Rp5.000.000 before 16 May 2023, 2:59PM to avoid automatic cancellation" is not a copywriting decision. It is a design decision that prevented financial errors in a high-stakes flow. Generic fintech copy in that same screen would have caused real harm.
The internal tool is part of the service. The Retool dashboard was not a side task. The SJ-facing flow and the finance tool were one system. Designing them separately would have created seams the user eventually falls through.
Organisational alignment is design work. Getting leadership confident enough to ship a change this significant required the same clarity of thought as the product design itself. Understanding what each stakeholder needed to feel certain about, and structuring the presentation around those needs, was as deliberate as any screen I designed.