Upfront Discounts

Permission node: BILLING.PLANSAPI: /api/v1/billing/upfront-discounts

An upfront discount rewards paying a term's balance in full at the start rather than instalments — the counterpart to a payment plan.

Action	Endpoint	Gate
List	GET /billing/upfront-discounts	BILLING.PLANS
Get one	GET /billing/upfront-discounts/{discountID}	BILLING.PLANS
Create	POST /billing/upfront-discounts	BILLING.PLANS
Update	PATCH /billing/upfront-discounts/{discountID}	BILLING.PLANS
Delete	DELETE /billing/upfront-discounts/{discountID}	BILLING.PLANS
What one student qualifies for	GET /billing/students/{studentID}/upfront-discount/{termID}	RECORDS.STUDENT_FINANCIAL

Note the last row: reading an individual student's discount is a different permission from configuring the scheme. Someone who administers discounts does not automatically get to read a named student's financial position, and a cashier answering a student's question does not get to change the scheme.

Checking before announcing

GET /billing/students/{studentID}/upfront-discount/{termID} answers what a specific student would receive for a specific term. Use it on a handful of real students across different student types and campuses before publishing a new discount — eligibility interacts with student type and with the fee categories on the term's fees, and the interaction is easier to verify than to reason about.

Timing against the payment deadline

The discount is only meaningful while paying in full is still possible, so its window has to sit sensibly against the term's first_billing_date and the payment-plan enrolment deadline. A discount that expires before bills are issued rewards nobody; one that runs past the plan deadline invites students to miss the plan while waiting.

Changing an existing discount

As with fees, charges already posted are not recalculated. A student who paid under the old terms keeps what they were given. Adjust for a future term rather than editing a discount that has already been applied.