KoronaPay - Credit Limit: Debt Repayment
Product Designer
KoronaPay is an international money transfer service, working in 50+ countries. Inside the app, there is a digital wallet and a payment card called KoronaCard - the financial center where users store money, manage their balance, and use a credit limit. Tens of thousands of active cardholders.
My role
Designed the debt repayment flow for the credit limit feature across two entry points
Ran interviews with users and internal stakeholders to define the processing-state UX
Results
Delivered two flows (full repayment, blocked limit) covering three dev teams' scope
Support tickets on this topic dropped to zero after launch - only genuine payment failures remain
The user paid, but saw no result for 24 hours
The problem came from two sides at the same time - from support, who kept getting the same complaints, and directly from the analysts' requirements. The user paid off their credit limit debt, but nothing changed in the transaction history - not the interest, not the late fee, not even the payment itself. Full repayment needed up to 24 hours to sync with the acquiring system. During that whole time, the user still saw the old debt widget, as if the payment never went through.
For someone who just sent money, this looked like a failed payment, not a technical delay.
Before
Payment confirmed by the bank - nothing changed on screen
After
Same debt widget, 24 hours later - still no update
Interviews from both sides: users and support
I ran 8 interviews - 5 with KoronaCard users and 3 with support staff.
I didn't pick users randomly. I went through support and found people who had already written in the chat with messages like "I don't see any change after paying" in the past few weeks. This gave me access to people who actually hit the problem, instead of guessing based on the general cardholder audience. The format was a free conversation based on a guide, not a strict script - I wanted to hear how people described what happened in their own words, not confirm an idea I already had.
For support, I picked people with different roles and experience - a chat operator, a senior specialist, and a team lead - to see both the front line (what people write in the moment) and the bigger picture (how often it happens, the pattern, the load on the team).
8 interviews, one shared finding: silence after payment reads as failure.
Users described the problem simply: "I paid, and the app shows the same thing - does that mean the money is gone?" Nobody knew about the 24-hour delay, because nothing in the app explained it. Silence was read as a failure, not as a process.
Support confirmed it: this topic is one of the most common reasons people write in, especially in the first few hours after payment. Users weren't complaining about fees or loan terms - they were anxious because there was no feedback.
This narrowed the task: we didn't need to make the sync with the acquiring system faster. We needed to close the gap in how the wait felt.
Two entry points, one flow
Paying off credit limit debt starts from two different places, but both lead to the same payment process.
First entry - from the home screen, where a widget shows the minimum payment or full debt amount, with a "Pay" button.
Payment is due but nothing is blocked yet — the MOP widget follows the user from Home to Card to Money, always showing the same amount and deadline.
Second entry - when the credit limit is already blocked due to a missed payment. Instead of a balance, the card shows a "Blocked" status, all actions are disabled, and the only option is to pay off the debt to unblock the limit.
The card itself goes grey and inactive across all three screens — visual state matches the functional one. "Pay" is no longer optional; it's the only way back into the account.
Both entries lead to the same payment process, but the card's state tells the user something different each time: in the first case - "you still have time, here's what's due." In the second - "access is closed, paying is the only way forward."
We replaced the debt widget with a processing status
The key decision - after a full payment, the old debt widget doesn't stay on screen in its old form. Instead, there's a confirmation screen: "Payment made," a checkmark icon, and the line "Your balance will update in a few minutes." The user clearly sees that the system recorded the payment, even if the real numbers in the history update a bit later.
Confirmation is instant — the debt widget's old spot now shows the payment fact, not a waiting screen.
This separated two things that used to blur into one: "the payment went through" and "the data is synced." The first happens instantly and should be visible right away. The second can take time, and that's fine - as long as we tell the user explicitly.
After confirmation, the home screen card updates too - the available limit goes back to full, and the "Blocked" status is removed where it applies.
Before choosing the status card, I looked at 5 concepts
I considered five different formats for payment confirmation. Each solved the problem in its own way, and each had a cost.
A toast disappears in a few seconds, while the old debt widget with outdated numbers stays on screen. A full-screen modal is too heavy a gesture for a routine action - it blocks the whole screen and needs an extra tap to close. A "processing" widget is technically honest, but leaves the user in limbo exactly when they need reassurance. A small badge is too quiet - in interviews, users already tended to miss the status, and a badge would only make that worse.
None of the screens confirm the payment instantly, in the place the user already looks — so the search continued.
I chose a status card in the same spot as the old widget. It takes up the same place in the interface - the user doesn't have to look for something new, they look where they always looked. It shows two facts separately: a green "payment made" checkmark instantly, and the familiar "Amount / Due date" fields, with a note that the balance will update soon. Nothing needs to be closed, and a fresh entry in the transaction history right below the card gives a second, independent confirmation without extra screens.
Out of five options, only this one answered the real question - not "explain the process," but "confirm the fact," while staying in the place the user already knows.
There was a separate, related problem inside the transaction history itself
While the confirmation screen solved the problem of the payment moment, a second, related problem came up - the KoronaCard transaction history didn't show credit limit payments at all: not the loan payment, not the interest, not the late fee. The user only saw transfers and purchases - everything related to the credit limit stayed completely invisible, not delayed, just missing.
We added a new transaction type to the history - with the payment system's icon, the amount, and the label "Loan payment" in the general list. In the transaction details - a separate field, "Transaction type: Interest and late fees," plus the date, time, and status. This gave users something they never had before: the ability to see exactly where the money went when it was deducted - not just "minus this amount," but specifically interest and late fees as their own category.
Operation type: Interest and late fees — shown as its own field, not folded into a generic debit.
Working with three development teams at once
Three analysts and three development teams (three developers each) worked on this feature, along with a product owner and me as the product designer. The task touched several systems at once - the transaction history, the card status on the home screen, and the acquiring system integration - and each team owned a different layer, each working from their own part of the requirements from the analysts.
Once all three parts were ready, I walked through the entire user journey myself - from the blocked limit to the entry in the history - specifically to catch mismatches that don't show up when you only look at one spec in isolation. Each team could perfectly deliver their own requirement, and there could still be a contradiction at the seams between screens that no single team would notice - simply because none of them had the full picture of the whole journey.
That's exactly how I found the gap described below.
What we missed at first: the card and the history didn't match
We had already decided what the history entry would show - the transaction type, the fields, the labels (see above). But we hadn't thought through when it would actually appear there.
During development, we found a mismatch: if the user pays off the debt, lands on the confirmation screen, and then immediately opens the transaction history - there might be no new entry yet, because the sync with the acquiring system isn't instant. The screen says "payment made," but the history is still empty - this could look like the exact same contradiction we were trying to remove.
The fix was to clearly separate what each screen is responsible for. The confirmation screen doesn't claim that everything is updated everywhere - it only confirms the fact of the payment. The line "Your balance will update in a few minutes" was written on purpose to cover both the widget and the history, so the user isn't surprised if they check the history right after and don't see a new entry yet.
Summary
The real problem wasn't backend speed - it was the silence in the interface while the user waited. If someone is paying real money, they won't tolerate uncertainty. The screen needs to say what happened, even if it can't say exactly when everything else will update.
After launch, support tickets on this topic dropped to zero - only real payment failures remained, meaning actual technical issues, not confusion about what happened. We didn't track exact numbers before and after, but the shift from "one of the most common topics" to "almost never comes up" was clear without any special analytics.
We split the fact of payment and the fact of syncing into two separate messages - and the transaction history finally showed a clear trail of where the money goes when interest and late fees are deducted.
The full flow, end to end — both scenarios, full repayment and blocked limit, and how the interest charge shows up in history.