Payment plans — policy & review queue
A payment plan lets a member pay one invoice in instalments instead of all at once. Members request; you decide.
Two things are worth understanding before you turn this on:
- A plan never changes what is owed. It is a schedule, not a discount and not a write-off. The balance still comes from the payments actually recorded against the invoice.
- A pending request pauses the overdue clock. While an in-policy request is waiting on you, that invoice will not flip to overdue and its dunning notice will not go out. That protection expires on a clock — which is why the queue is sorted the way it is.
Turn payment plans on
Payment plans are off by default for every organization. A plan is a concession, not a default entitlement, so nothing changes for your members until you opt in.
Org → Settings → Billing, then find the Payment Plan Policy card.
Switch on Allow payment plan requests. Until you do, no member or officer sees any way to ask for a plan, and the rest of the card has no effect.
Switching it back off stops new requests; it does not cancel plans you have already approved. Those stay in force — their instalment dates still hold and they still hold off dunning — so members who have one keep seeing their schedule and their request history. To end a specific plan, act on that plan rather than on this switch.
Set the policy limits
These fields define what counts as an in-policy request. They do not block anyone from asking for something else — an out-of-policy request still arrives in your queue, it just arrives flagged, and it earns no pause on the overdue clock.
| Setting | Default | What it means |
|---|---|---|
| Who may submit a request | The member, or an officer on their behalf | Restrict to the member only if you don't want officers filing for others |
| Maximum instalments | 4 | Minimum is 2 — a plan of one instalment is just the invoice. Maximum is 120, which is the longest schedule the API will render |
| Maximum plan length (days) | 120 | The span from the first instalment to the last |
| Minimum first payment ($) | 0 | The smallest acceptable down payment |
| Auto-approve requests inside these limits | Off | See the warning below |
| Regional admins may review requests | Off | Widens the reviewer tier beyond national admins |
Auto-approve is off by default, deliberately
Auto-approve requests inside these limits exists, but it starts off. With it off, every single request waits for an explicit human decision, however reasonable it looks.
Turn it on only if you genuinely want in-policy requests granted without review. It is a real delegation of authority: a member who stays inside your limits gets a plan immediately, and you find out afterwards.
Officers submitting on a member's behalf
An officer filing for a member is a convenience, never an escalation. Submitting on someone's behalf confers no approval authority — the reviewer is still an admin, including when the officer files for themselves.
If your organization hides balance amounts from officers (Officers see amounts, on the same settings screen), an officer who files on a member's behalf will see that member's balance shown as Hidden rather than a figure.
Work the review queue
Org → Operations → Payment Plans.
The page is titled Payment Plan Requests and shows the pending queue.
Why it is sorted by freeze, not by age
The queue is ordered by freeze expiry, soonest first — not oldest-first, and the ordering is applied by the server across the whole queue, not just the page you're looking at.
This matters because the request most in need of your attention is not usually the oldest one. A pending, in-policy request pauses its invoice's overdue transition, but only until a window anchored to that invoice's own due date runs out. Once it lapses, the invoice resumes accruing and the member gets a dunning notice — even though the request is still sitting there unanswered. Sorting by age would bury the request that is about to lose its protection behind older requests whose invoices aren't due yet.
A Next freeze to lapse panel at the top carries a live countdown for the most urgent request, and every row shows its own.
Reading a row
Each request shows the member, the invoice and its due date, the requested instalments and first payment, the member's justification, and a badge reading either In policy or Outside policy.
An Outside policy request is not rejected automatically — it is yours to judge. But note it never earned a freeze, so its invoice has been accruing normally the whole time it has been waiting.
Approving and refusing
Per row, Approve grants the schedule, or you can refuse. A Review note field records why, and a refusal does not persist the requested numbers as though they had been granted.
For the common case, Approve all in policy grants every request currently inside your limits in one action, leaving the out-of-policy ones for you to judge individually.
After approval
An approved request becomes a schedule the member can see for themselves — see Paying dues & invoices.
Instalments are reconciled manually in this version. Approving a plan does not set up automatic collection and does not charge a card on a schedule. Payments are recorded as they arrive, the same as any other payment, and the balance derives from them as it always has.