While designing the database and Product Requirements Document (PRD) for an online school project, I ran into a problem I was not expecting.
The school had multiple subscription plans.
For simplicity, imagine:
Live Class Plan:₦50,000 per term
Video On Demand Plan: ₦30,000 per term
Hybrid Plan (Live Classes + Video On Demand):₦70,000 per term.
Initially this looked simple.
Students subscribe.
System charges them.
Done.
Then I asked:
What happens if somebody changes plans halfway through the term?
Suppose:
A student already paid:
Live Class Plan
₦50,000
Two months later:
They decide:
Upgrade to Hybrid Plan
Do we charge:
₦70,000 again?
That would be unfair.
Do we charge:
₦20,000 difference?
Maybe.
But what if they already used most of their subscription period?
This question led me to something called:
Proration
What Is Proration?
Proration simply means:
Charging customers only for the portion they actually use.
Instead of pretending subscriptions always begin and end perfectly.
Proration tries to answer:
"How much value remains in the current subscription?"
and
"How much should the customer pay for the new one?"
Simple Example
Assume:
Term Length:
100 Days
Student buys:
Live Plan
₦50,000
After:
40 Days
they upgrade.
This means:
Used:
40 Days
Remaining:
60 Days
Value remaining:
Remaining Value
= Remaining Days / Total Days
= 60 / 100
= 60%
Remaining credit:
60% × ₦50,000
= ₦30,000
Hybrid costs:
₦70,000
Therefore:
Amount to bill
= New Plan Price − Remaining Credit
= ₦70,000 − ₦30,000
= ₦40,000
Student pays:
₦40,000
instead of:
₦70,000
This feels fairer.
Downgrades Are More Complicated
What if:
Hybrid user:
₦70,000
moves to:
₦30,000 plan
Should the system:
- Refund money?
- Create account credits?
- Apply discount later?
- Ignore downgrades until renewal?
This is where:
Proration Rules
become important.
What Are Proration Rules?
Proration calculations are useless without rules.
The business must decide:
Rule 1: How Is Remaining Value Calculated?
Options:
- Daily basis
- Weekly basis
- Monthly basis
Example:
Daily proration
usually produces more precise billing.
Rule 2: What Happens During Upgrades?
Example:
Immediately upgrade
Immediately bill difference
OR
Upgrade at next renewal
Rule 3: What Happens During Downgrades?
Possible rules:
- Refund money
- Store credits
- Ignore until renewal
Rule 4: Should Used Features Affect Billing?
Imagine:
Hybrid includes:
- Live classes
- Recorded videos
- Assignments
What if:
Student already watched:
95% of videos
Should remaining credit still be full?
Business rules become complicated quickly.
How I Started Thinking About It As A Backend Developer
Initially I thought:
"I only need payment tables."
Eventually I realized:
I also need to track:
Subscription Table:
id
student_id
plan_id
start_date
end_date
status
Plan Change Table:
id
old_plan
new_plan
credit_applied
amount_charged
changed_at
Because billing decisions require historical information.
Without history:
You cannot calculate proration.
The Formula That Helped Me Think About Proration
The simplified version I now think about is:
Remaining Credit
=
(Remaining Time / Total Subscription Time)
×
Current Plan Price
Then:
Amount To Charge
=
New Plan Price
−
Remaining Credit
Simple formula.
Complicated business rules.
What I Learned
Initially I thought subscriptions meant:
User Pays
→ Access Granted
What I discovered was:
Subscriptions are mostly:
Business Rules
+
Edge Cases
+
Lots Of Questions
Proration taught me something important:
Billing systems are rarely difficult because of mathematics. They are difficult because products have rules.
Now whenever I design subscription systems I ask:
"What happens when somebody changes their mind halfway through?"
Because eventually:
Somebody always does.
Have you ever implemented subscriptions or billing logic?
How would you handle upgrades and downgrades?
Top comments (0)