Handle monthy allowance for new members when opencollective payments occur less than month apart #45
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: co-op/support#45
Reference in new issue
Block a user
What's the idea?
Members can join any day of any month, and their allowance gets reset on the day of each month determined by their join date. However, opencollective charges members (approximately) on the first of each month. According to deepseek, there are two payment schedule scenarios:
A) if the user signed up before or on the 15th of the month, they will be charged the full amount on the 1st of the next month
B) If the user signed up after the 15th, the next month will be skipped and they will be charged on the 1st of the following month
Scenario A is the one I'm focused on, because it means people paid more than their monthly due for a one month period, yet they did not receive more than one month's allowance. This seems unfair.
Scenario B actually has the opposite problem: the user gets more than they paid for. I'm not sure if there's a worthwhile solution to that but definitely open to discussion.
For Scenario A, @ntnsndr's suggestion was to add a pro-rated amount to the allowance. That seems like the best solution to me at the moment, though I haven't thought through the options carefully.
Why does it matter?
Some new members may feel they are being charged without getting the full benefit in allowance.
Who is it for?
New members (specifically ones who joined the coop on or before the 15th of the month)
How might it work?
If opencollective charges a new member prior to one month since the first payment, a pro-rated allowance can be added for that member.
Thanks @jbwexler — you've read this correctly, and the analysis matches ours.
Scenario A is already handled. The allowance renewal is anchored to each member's join day, while Open Collective charges onto the collective's billing day, so a member who joins early in a month can be charged again before their first month is up and receive less allowance than the period they paid for. The portal now detects that automatically and credits the difference as dollar-equivalent, non-expiring credits, pro-rated by the days lost, with the ledger entry naming the charge it came from. It applies to any truncated paid cycle, not just a first one, it runs on its own for every future member, and it is not something anyone has to claim.
Scenario B — the opposite case — we are inclined to leave alone, and your instinct to raise it rather than assume is the right one. Someone joining late in a month can end up with more allowance than they paid for. We correct shortfalls; chasing overshoots would cost more in complexity and member trust than it recovers. That's where we've landed, and it's open to revisiting if it turns out to be more common than we think.
On being surprised by the timing: we agree, and the fix isn't only the credit. A note is going into the welcome email explaining that a second charge may arrive sooner than a month after joining, so the timing is expected rather than a nasty surprise, and that any shortfall is credited automatically.
Finding the asymmetry was the useful part — it's not something our own data flagged.
This was resolved around the time I wrote this, so I will close the issue.