Policy: monthly allowance renews on a live Open Collective contribution, anchored to the join day #44

New Issue

2026-11-04T05:20:34Z

inference-bot commented

2026-11-04 05:20:34 +00:00

Decision (2026-11-04). How a member's monthly allowance renews, and how a lapse is handled, is now explicit and recorded here so it is not lost.

The policy

Which members renew is decided by asking Open Collective directly, on our own schedule, whether the member has a live recurring contribution — not inferred from webhook delivery, so a missed webhook costs a delayed renewal, never a lost month.
The renewal is anchored to the day of the month the member joined, not the day Open Collective charged them. Open Collective aligns charges onto the collective's common billing day, so a charge could move a member's renewal and skip a cycle entirely (a member who joined on the 15th was charged on the 2nd, and his reset moved from the 14th to the 2nd of the next month with no reset in between).
A member with no live contribution gets one reminder email, and is deactivated only after a grace period.
Deactivation means losing group access while keeping the account, so a returning payer resumes cleanly.
Every decision (renewed / reminded / deactivated, with the payment date or its absence) is logged, so a member's question is answered from the record rather than reconstructed.

What we checked

Open Collective today shows 104 orders: 87 monthly, 17 one-time, zero annual. So only the monthly case needs a branch — one-time payments stay in the existing credit model (they top up a non-expiring balance; they are not an allowance cycle).

Status

The mechanism is deployed in the member portal and running in report-only mode until the first list is reviewed; no member is deactivated by it yet. Related class of bug: #42.

Decision (2026-11-04). How a member's monthly allowance renews, and how a lapse is handled, is now explicit and recorded here so it is not lost. **The policy** - Which members renew is decided by asking Open Collective directly, on our own schedule, whether the member has a **live recurring contribution** — not inferred from webhook delivery, so a missed webhook costs a delayed renewal, never a lost month. - The renewal is anchored to the day of the month the member **joined**, not the day Open Collective charged them. Open Collective aligns charges onto the collective's common billing day, so a charge could move a member's renewal and skip a cycle entirely (a member who joined on the 15th was charged on the 2nd, and his reset moved from the 14th to the 2nd of the next month with no reset in between). - A member with no live contribution gets **one** reminder email, and is deactivated only after a grace period. - Deactivation means losing group access while **keeping the account**, so a returning payer resumes cleanly. - Every decision (renewed / reminded / deactivated, with the payment date or its absence) is logged, so a member's question is answered from the record rather than reconstructed. **What we checked** Open Collective today shows 104 orders: 87 monthly, 17 one-time, zero annual. So only the monthly case needs a branch — one-time payments stay in the existing credit model (they top up a non-expiring balance; they are not an allowance cycle). **Status** The mechanism is deployed in the member portal and running in **report-only** mode until the first list is reviewed; no member is deactivated by it yet. Related class of bug: #42.

inference-bot referenced this issue from a commit

2026-11-04 05:20:46 +00:00

membership: record the allowance renewal and lapse policy (2026-11-04)

inference-bot referenced this issue from co-op/ops-docs

2026-11-04 05:20:48 +00:00

membership: allowance renewal and lapse policy #2

inference-bot commented

2026-11-05 04:51:53 +00:00

Closing: the policy is implemented and verified, not just decided.

Shipped: renewals decided by asking Open Collective directly (a missed webhook costs a delayed renewal, never a lost month); the cycle anchored to the join day, with the boundary clamped to the 28th so a member who joined on the 29th-31st is never skipped in a short month; the single reminder; the grace window; every decision logged with its evidence. Renewals and reminders now run on schedule, and 82 members' cycles were re-anchored to their join days in the first applied run.

One clause has not yet been exercised in production: deactivation after grace. It is implemented, gated behind its own flag, and deliberately still off. The first member to reach that point does so on 11 November, and that is the case that will prove the last clause end to end. If it misbehaves, this reopens.

Related, and worth keeping together: the companion rule for members whose paid cycle Open Collective's billing day truncated -- a pro-rated allowance credit, applied automatically and idempotently -- is recorded in #45 with the member who raised it. Both rules come from the same billing-day behaviour and should be read as a pair.

Closing: the policy is implemented and verified, not just decided. **Shipped:** renewals decided by asking Open Collective directly (a missed webhook costs a delayed renewal, never a lost month); the cycle anchored to the join day, with the boundary clamped to the 28th so a member who joined on the 29th-31st is never skipped in a short month; the single reminder; the grace window; every decision logged with its evidence. Renewals and reminders now run on schedule, and 82 members' cycles were re-anchored to their join days in the first applied run. **One clause has not yet been exercised in production:** deactivation after grace. It is implemented, gated behind its own flag, and deliberately still off. The first member to reach that point does so on 11 November, and that is the case that will prove the last clause end to end. If it misbehaves, this reopens. **Related, and worth keeping together:** the companion rule for members whose paid cycle Open Collective's billing day truncated -- a pro-rated allowance credit, applied automatically and idempotently -- is recorded in #45 with the member who raised it. Both rules come from the same billing-day behaviour and should be read as a pair.

inference-bot closed this issue

2026-11-05 04:51:53 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: co-op/support#44