Show price cadence and require a pay agreement at booking

Every price a student meets on the front end now carries the cadence it is billed on — at booking, up front, weekly, monthly — so a bare amount can no longer read as a one-off when it is a recurring charge. Both registration forms then restate the price and require a second, separate tick agreeing to pay it, distinct from the policy acceptances above it. The agreed figure includes the studio HST so it matches Payment::total(), the amount actually billed; the rate reaches the browser as a new localized `taxRate`. A weekly reservation is charged per lesson for every week it claims, and a week another student takes first is simply not claimed, so its total is quoted as a ceiling ("up to 12 lessons") rather than a promise. Free offerings have nothing to agree to and show no price block at all. The formatting and the agreement live in one shared helper (`window.usPricing`, registered as `us-scheduler-pricing`) so a price reads the same in the booking form, the class catalogue and the editor preview. Closes #124 Co-Authored-By: Claude Opus 5 <[email protected]>
2026-07-28 14:43:38 -03:00
parent d6a515cc93
commit 9344ab7193
12 changed files with 380 additions and 18 deletions
@@ -35,6 +35,11 @@ An offering is anything a student can register for: a private-lesson type (30 or
 - `weekly` — **not** charged at registration; a pending payment for one lesson's fee is generated **24 hours before each lesson** by the daily billing scan.
 - `monthly` — **not** charged at registration; on the **1st of each month** a single pending payment is generated for every lesson that falls in that month (4 lessons ⇒ 4 × fee).

+Students see the mode as a **cadence** beside every price on the front end — *at
+booking*, *up front*, *weekly*, *monthly* — and confirm it explicitly before a
+booking or enrolment goes through. See **Price Display and the Pay Agreement** in
+`payments.md`.
+
 `weekly` and `monthly` are *scheduled* billing (`Offering::isScheduledBilling()`): the
 booking/enrolment succeeds with no payment step, and payments are created later by the
 daily `us_generate_due_payments` cron scan. See `scheduled-billing.md` and `payments.md`.