Understand recurring schedules, paid installments and donor receipt controls

This article covers gifts made through GiveCampus. Payment and recurring-gift options depend on the institution and the form.

Open the authorized recurring-management page and review Next Payment, Installment Amount, frequency and end date before editing. Updating the schedule does not increase or refund an already processed installment. A separately authorized additional gift may be needed when the donor wants to give more for a payment already collected; first verify the existing charge to avoid duplication.

The scheduler supports monthly and yearly frequencies. The editor restricts those further to the form's enabled options; limited months maps to monthly. Weekly is not offered in this workflow. Monthly dates use calendar-month progression, with a day beyond the target month's length capped at month end in the updated-day calculation. For example, the scheduled monthly date after May 31 is June 30 rather than an automatic July 1. Verify the saved Next Payment for the actual subscription and processor; scheduled charge dates and bank settlement dates are different.

The editor can change Next Payment, with a separate option to run future payments on that day where offered. Moving a date does not apply a separate advance gift to the commitment or automatically reduce its balance. A skip-one-payment or credit-external-gift request requires reconciliation of the intended remaining schedule with support. Do not cancel the entire subscription merely to avoid one charge.

Paid Installments displays the subscription's associated installment records. Eligible rows provide Resend Installment Receipt to donors/private-link holders as well as administrators, subject to request authorization. Edit Installment and the available Download Receipt link in that panel are administrator-only. Other controls depend on gift type, processor, state and modify permissions; the views are not identical. A resend queues delivery rather than guaranteeing immediate receipt.

The recurring-data import sets up future payments and initializes recorded paid charges to zero; it does not populate pre-migration historical payments into this table. A prior gift in another system is not automatically an associated GiveCampus installment. Ask support to evaluate supported historical-data handling rather than creating fictitious processed payments or promising a self-service history editor.