

Videoland Bad Debt Flow Redesign
Videoland Bad Debt Flow Redesign
Videoland Bad Debt Flow Redesign
Payment flow
Payment flow
Payment flow
Redesigning the payment recovery flow for users with failed or overdue subscription payments, reducing friction and clarifying next steps.
Redesigning the payment recovery flow for users with failed or overdue subscription payments, reducing friction and clarifying next steps.
Redesigning the payment recovery flow for users with failed or overdue subscription payments, reducing friction and clarifying next steps.
1. Context
1. Context
1. Context
Videoland users whose subscription was cancelled after a failed payment (e.g. insufficient funds) land on a recovery screen. This flow had to do two things at once: clearly explain what happened, and make it as easy as possible to regain access. The flow was designed mobile-first, reflecting how most subscription and billing interactions on Videoland actually happen.
Business goal: Unpaid invoices represent direct revenue loss, so the underlying business objective was straightforward: recover outstanding payments. The existing flow was actually working against that goal — forcing users to pay multiple invoices one by one added friction at exactly the moment you want someone to complete a payment. The redesign wasn't about balancing customer needs against the business goal; removing that friction served both at once. A simpler, clearer flow made users more likely to actually complete payment, which improved the experience and directly supported revenue recovery.
Videoland users whose subscription was cancelled after a failed payment (e.g. insufficient funds) land on a recovery screen. This flow had to do two things at once: clearly explain what happened, and make it as easy as possible to regain access. The flow was designed mobile-first, reflecting how most subscription and billing interactions on Videoland actually happen.
Business goal: Unpaid invoices represent direct revenue loss, so the underlying business objective was straightforward: recover outstanding payments. The existing flow was actually working against that goal — forcing users to pay multiple invoices one by one added friction at exactly the moment you want someone to complete a payment. The redesign wasn't about balancing customer needs against the business goal; removing that friction served both at once. A simpler, clearer flow made users more likely to actually complete payment, which improved the experience and directly supported revenue recovery.
Videoland users whose subscription was cancelled after a failed payment (e.g. insufficient funds) land on a recovery screen. This flow had to do two things at once: clearly explain what happened, and make it as easy as possible to regain access. The flow was designed mobile-first, reflecting how most subscription and billing interactions on Videoland actually happen.
Business goal: Unpaid invoices represent direct revenue loss, so the underlying business objective was straightforward: recover outstanding payments. The existing flow was actually working against that goal — forcing users to pay multiple invoices one by one added friction at exactly the moment you want someone to complete a payment. The redesign wasn't about balancing customer needs against the business goal; removing that friction served both at once. A simpler, clearer flow made users more likely to actually complete payment, which improved the experience and directly supported revenue recovery.

The entry point after a failed payment. The screen explicitly explains what happened and why, avoiding vague or alarming language, while giving the user two clear paths forward: reactivate immediately, or pay outstanding invoices first.
The entry point after a failed payment. The screen explicitly explains what happened and why, avoiding vague or alarming language, while giving the user two clear paths forward: reactivate immediately, or pay outstanding invoices first.
The entry point after a failed payment. The screen explicitly explains what happened and why, avoiding vague or alarming language, while giving the user two clear paths forward: reactivate immediately, or pay outstanding invoices first.
The Problem
The Problem
The Problem
Users with multiple outstanding invoices previously had to settle each invoice separately. This is still visible on the entry screen: each invoice is listed individually with its own "Betaal factuur" (Pay invoice) link.
Users with multiple outstanding invoices previously had to settle each invoice separately. This is still visible on the entry screen: each invoice is listed individually with its own “Betaal factuur” (Pay invoice) link.
Users with multiple outstanding invoices previously had to settle each invoice separately. This is still visible on the entry screen: each invoice is listed individually with its own “Betaal factuur” (Pay invoice) link.

Before the payment step itself was redesigned, each outstanding invoice required a separate action — adding friction for users who simply wanted access restored.
Before the payment step itself was redesigned, each outstanding invoice required a separate action — adding friction for users who simply wanted access restored.
Before the payment step itself was redesigned, each outstanding invoice required a separate action — adding friction for users who simply wanted access restored.
3. The Solution
3. The Solution
3. The Solution
In the actual payment flow, multiple outstanding invoices are now combined into a single total and a single payment action, instead of being settled one by one.
In the actual payment flow, multiple outstanding invoices are now combined into a single total and a single payment action, instead of being settled one by one.
In the actual payment flow, multiple outstanding invoices are now combined into a single total and a single payment action, instead of being settled one by one.

Instead of settling invoices one by one, users now see a single combined total — in this case, two outstanding invoices plus the upcoming subscription period — and complete payment in one step.
Instead of settling invoices one by one, users now see a single combined total — in this case, two outstanding invoices plus the upcoming subscription period — and complete payment in one step.
Instead of settling invoices one by one, users now see a single combined total — in this case, two outstanding invoices plus the upcoming subscription period — and complete payment in one step.
4. Two Paths, One Consistent Pattern
4. Two Paths, One Consistent Pattern
4. Two Paths, One Consistent Pattern
The flow supports two scenarios: reactivating immediately (invoices + new subscription in one payment), or simply settling outstanding invoices without reactivating right away.
The flow supports two scenarios: reactivating immediately (invoices + new subscription in one payment), or simply settling outstanding invoices without reactivating right away.
The flow supports two scenarios: reactivating immediately (invoices + new subscription in one payment), or simply settling outstanding invoices without reactivating right away.


Two distinct user intents — reactivate now, or just clear the debt — share the same clear, combined-payment pattern, keeping the experience consistent regardless of path.
Two distinct user intents — reactivate now, or just clear the debt — share the same clear, combined-payment pattern, keeping the experience consistent regardless of path.
Two distinct user intents — reactivate now, or just clear the debt — share the same clear, combined-payment pattern, keeping the experience consistent regardless of path.
5. Process / My Role
5. Process / My Role
5. Process / My Role
Revised the messaging on the error screen: transparent but not accusatory
Redesigned the payment step: from separate, repeated actions into a single bundled transaction
Applied previously validated A/B test patterns from the broader payment flow
Designed for both desktop and mobile, maintaining consistent hierarchy across breakpoints
Revised the messaging on the error screen: transparent but not accusatory
Redesigned the payment step: from separate, repeated actions into a single bundled transaction
Applied previously validated A/B test patterns from the broader payment flow
Designed for both desktop and mobile, maintaining consistent hierarchy across breakpoints
Revised the messaging on the error screen: transparent but not accusatory
Redesigned the payment step: from separate, repeated actions into a single bundled transaction
Applied previously validated A/B test patterns from the broader payment flow
Designed for both desktop and mobile, maintaining consistent hierarchy across breakpoints
6. Reflection
6. Reflection
6. Reflection
This project reinforced how much clarity matters in financially sensitive moments — the difference between a user feeling confused or penalized versus informed and in control often comes down to small wording and structural choices, not just visual polish. It also reinforced that customer-first and business-first aren't always in tension — here, they pointed in the same direction, and the strongest design insight was recognizing that removing friction served both.
This project reinforced how much clarity matters in financially sensitive moments — the difference between a user feeling confused or penalized versus informed and in control often comes down to small wording and structural choices, not just visual polish. It also reinforced that customer-first and business-first aren't always in tension — here, they pointed in the same direction, and the strongest design insight was recognizing that removing friction served both.
This project reinforced how much clarity matters in financially sensitive moments — the difference between a user feeling confused or penalized versus informed and in control often comes down to small wording and structural choices, not just visual polish. It also reinforced that customer-first and business-first aren't always in tension — here, they pointed in the same direction, and the strongest design insight was recognizing that removing friction served both.
© Rui Jun Mei 2026
© Rui Jun Mei 2026
© Rui Jun Mei 2026