Recurring Payments

The same scheduling engine runs three different kinds of recurring activity. Donor recurring giving is set up on the public donation form — documented in detail on the Donations feature page. Customer recurring service payments are set up at invoice time when a payment plan is appropriate — documented inside the Accounting & Payments story. Customer deposits are set up by patrons pre-loading their accounts. Three context-specific surfaces, one engine underneath. No separate "Recurring" feature to learn, no separate UX to context-switch into.

Every night, SecureCare's recurring processor runs in three passes — customer payments and deposits, donor recurring donations, anonymous invoice payments — each pass grouping a person's payments together so all of one person's activity processes before moving on. Successful runs schedule the next month's date automatically. Failed runs are logged with the failure reason for staff review. The processor is idempotent and self-healing: a missed nightly run picks up where it left off the next night without double-charging.

For invoice-based recurring payments, every nightly run caps the charge at the invoice's remaining balance — so the final payment in a series is automatically reduced to whatever's actually owed, not the full monthly amount. When the balance hits zero, the schedule suspends itself and any pending future charges are cancelled. No overpayment, no manual final-month adjustment, no staff intervention required to wind down a paid-off plan.

When a recurring payment lands on an invoice with multiple line items, the platform distributes the charge proportionally across the lines that still have remaining balance — capped to each line's individual balance due. No line gets overpaid; the books reflect what was actually paid against what was actually owed. This matters when a customer's invoice covers multiple program services: the recurring charge attributes to the right programs automatically, and the program-level reporting holds.

The public Pay Invoice flow — where a customer enters an invoice number and date of birth from the public site — can also accept a one-time payment plan setup. The recurring engine treats anonymous payment plans as its own pass, separate from identified-customer plans, so the books cleanly distinguish the two. The payer doesn't need a patron account, and staff don't need to be involved in the setup. Modifications after that point require staff intervention — the customer-side flow is intentionally one-shot to keep the books clean.

Cancelling a recurring payment soft-deletes the schedule, suspends it, and cancels every pending future charge in a single transaction. The historical record — what was set up, what ran, what cancelled, when — is preserved for audit.