Repayment Calendar for Pay-Later Purchases
Design a repayment calendar that combines installments across merchants and makes upcoming amounts, fees, and failed-payment recovery clear.
The brief
Understand the problem
Background
Pay-later purchases can feel separate at checkout but compete for the same bank balance on repayment days. A calendar should reveal total obligations and plan terms without encouraging additional borrowing.
User context
Talia has four active purchase plans from three merchants. Her pay date moved by two days, and she wants to see whether any installment is eligible for a schedule change.
Product problem
Talia needs one accurate view of dates, remaining balances, payment methods, and consequences before deciding how to handle a crowded week.
Objective
Create monthly overview, installment detail, permitted reschedule, and failed-payment recovery states.
What to design
Define the experience
Required experience
- Review total due by day and pay period
- Open a purchase plan and inspect its terms
- Check eligibility and consequences for changing one date
- Recover from a payment failure without losing schedule context
Screens and states
- Repayment calendar
- Purchase plan detail
- Date-change review
- Failed-payment recovery
Core user flow
Follow the critical path
- 01
Talia opens September and sees three installments due before payday
- 02
She selects a $64 payment and checks its change policy
- 03
The interface offers one fee-free date within the allowed window
- 04
She confirms the new date and reviews the updated weekly total
Product rules
Requirements and constraints
Requirements
- Aggregate obligations while preserving each plan's merchant and terms
- Show remaining principal, fees, due dates, and payment method
- Explain date-change eligibility before presenting options
- Update totals immediately after a confirmed change
- Provide support and hardship routes without promoting new credit
Constraints
- Eligibility and fees vary by plan and jurisdiction
- A reschedule cannot be implied until confirmed
- Bank processing dates may shift around public holidays
Reality check
States worth considering
Ready-to-use content
Mock data
Use this content to test hierarchy and realistic data states. You can expand it when the concept needs more depth.
September payments
- 4 September: $38 for headphones
- 6 September: $64 for shoes
- 6 September: $29 for cookware
- 18 September: $64 for shoes
Finish line
What to deliver
- Four mobile screens showing schedule review and one permitted date change
- A calendar component with due, processing, paid, failed, and changed states
If you want more
Optional extensions
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.