KoronaPay - Loan Repayment: Editable Amount in Grace Period
Product Designer
KoronaPay is an international money transfer service, working in 50+ countries. Inside the app, users also have access to loans - express loans with a grace period (an interest-free repayment window). Tens of thousands of active loan users.
My role
Unlocked the amount field for grace-period repayments and aligned the screen with the app's shared payment UI pattern
Designed and read the results of an A/B test on the SMS notification toggle to increase paid opt-ins
Results
Grace-period partial payments shipped with live commission recalculation
SMS toggle test ran 2 weeks: paid opt-in rate up from 20% to 22.8% (+14% relative), conversion flat (±1%)
Translated to +14% revenue from SMS notifications, based on ~100K monthly loan payments
Zero drop in repayment completion rate after unlocking the amount field
The product was deciding how much the user should pay, not the user
The ticket sounded technical at first - "unlock the amount field during the grace period." But behind it was a product assumption nobody had really questioned: during the interest-free period, the product assumed it's always better for the user to pay everything at once, so choosing an amount felt unnecessary. The logic made sense on paper - why pay in parts if there's no interest yet?
But users don't think in terms of interest rates. They think in terms of "how much money do I have right now." If a paycheck comes in parts, or some of the money is needed for something else, the user simply can't pay the full amount - and the product gave them no other option besides waiting. We were optimizing for the loan's financial logic, not for how people actually handle money in real life.
Before
The old flow only offered one number - the full amount due, with no way to change it
Unlocking the field, and bringing the screen in line with the rest of the app
We unlocked the read-only "Amount" field for grace-period loans, so users could enter any amount, not just the full debt. At the same time, we reworked the layout to match the shared payment UI pattern already used elsewhere in the app - amount and commission recalculating live at the bottom of the same screen, instead of a separate static breakdown. This wasn't just a fix for grace-period loans - it brought the loan repayment screen in line with how payment amounts and fees are shown everywhere else in KoronaPay.
After
Amount as an editable input, matching the pattern used across the rest of the app
Free-text amount input opened up four ways to break the screen
Once the field became editable, "let the user type any amount" turned out to be at least four separate scenarios that never existed before, when the amount was fixed.
Zero or empty field. The user accidentally clears the number completely - what happens to the "Next" button? We made it inactive, with a clear message under the field: "Enter the amount you want to pay."
Amount higher than the current debt. The user types 90 when the debt is €83.28 - we block "Next" and show the exact limit: "Enter an amount no higher than your debt - €83.28." We call out the specific number instead of a generic "too much."
Blocking the button isn't enough on its own — the message has to say exactly why, and by how much.
Default state of the screen. An empty field on open would feel like an extra step for the majority of cases where the user just wants to close the debt in full. We pre-filled the field with the full debt amount - "pay everything" is still the default, but now it's a starting point, not the only path.
SMS toggle and its effect on the total. The SMS notification fee (€1) needed to stay clearly tied to the toggle on the same screen - turn it off, and the user pays €0. Getting this pairing right mattered even more once we started testing the toggle's default state (see below).
The SMS toggle was mostly switched off - we tested where it should live
Separately from the repayment redesign, product metrics showed something worth testing: the SMS notification toggle - paid, informing the recipient that the payment went through - was being switched off by most users, sitting around a 20% opt-in rate. The business wanted to increase that without hurting how smoothly people completed the payment flow.
I designed three variants before landing on the one we tested.
Variant 1 - toggle directly on the payment screen, default OFF (original state). The toggle sat right in the amount screen, switched off by default. Fastest to scan, but the low opt-in rate showed most users just left it as-is without reading what it did.
Variant 2 - toggle directly on the payment screen, default ON. Simplest fix - flip the default, keep it in place. Risk: the explanation of what the SMS does and why it costs extra had no room to breathe next to the amount field - a toggle with no context reads as something to just switch off again.
Variant 3 - separate screen, opened via a chevron row, default ON (shipped). Moved the toggle to its own screen with full context - what the SMS confirms, why it costs more - and defaulted it to on. The main payment screen only shows a one-line summary - "Notify recipient by SMS - commission +€1" - so the user always sees the cost is included in the total before paying, without needing to open the second screen at all.
The toggle moved to its own screen with room to explain itself - the payment screen just shows the resulting cost
We shipped Variant 3. It gave the toggle enough space to explain itself properly - something that didn't fit next to the amount field - while defaulting to on. The commission was never hidden: it's visible both in the summary row and in the final total ("Commission: €1 + €1"), so an opt-in increase never came at the cost of transparency.
Working with the team
One team worked on this - an analyst and platform developers (iOS, Android, web) covering the shared payment flow across express loans, card repayment, and cash repayment. Every change had to work identically across all three loan scenarios, since they all lead into the same screen.
My part of the work was the edge cases and the screen logic itself. The original ticket only asked to "unlock the field" - it didn't mention what should happen on zero amount, over-limit input, or the default state. I walked through the new editable field myself, listed out every "what happens if..." case I could find, and wrote them up as annotated states for the analyst to turn into formal requirements - rather than leaving each platform to interpret edge-case behavior on its own. For the SMS toggle, I designed both variants tested (different default state and placement) and worked with analytics afterward to read the results together, translating the numbers into a concrete design recommendation for the next iteration. Because iOS, Android, and web were all building off the same screen at the same time, I kept a single source-of-truth spec for the field validation and toggle behavior, so no platform ended up out of sync with the others.
What stayed out of scope
Recalculating the future payment schedule in real time when a user pays part of the debt - discussed, not included in this round. The screen shows the total due right now, but doesn't automatically show how a partial payment changes the following months.
Summary
The ticket was written as "unlock the field" - but the real work was giving the client back a decision the product had been making for them, without breaking trust in the number shown on screen. The SMS toggle test showed the same principle from another angle: a small, well-placed UI change - not pressure or dark patterns - was enough to shift real behavior and add measurable revenue, while keeping the flow just as fast.
The full flow, end to end — every screen in this case study, on one diagram.