Fix two duplicate-charge bugs in scheduled billing #201

Merged

thatguygriff merged 2 commits from fix/duplicate-payment-due-notice into main 2026-09-17 18:25:19 +00:00

Conversation 1 Commits 2 Files Changed 21

+641 -12

2 Commits

Author	SHA1	Message	Date
Kydoimosandanthropic/claude-opus-4-8	acda3cda0f	Reconcile up-front charges when a class switches to monthly billing ... A student who enrols while a group class is pay-now is charged once at enrolment, and that charge carries no period_key. When the class is later switched to monthly, the daily scan — which dedups scheduled charges by period_key — does not see the up-front charge and bills the enrolment again for the current month, double-charging students who had already paid. The differing payer between the two rows (student vs guardian) was a side effect of guardian links created between the two charge dates, not the cause. Switching a group class into monthly now adopts each active enrolment's up-front charge into the current month (stamping period_key and due_date) so the scan treats that month as billed and charges from the next month on. Enrolments with no up-front charge, or already billed for the month, are left alone; weekly and non-group offerings are not touched. Wired into both offering-update paths (admin form and REST). Co-authored-by: anthropic/claude-opus-4-8	2026-09-17 15:07:22 -03:00
Kydoimosandanthropic/claude-opus-4-8	e389e40843	Send each scheduled payment's due notice exactly once ... The daily billing scan runs on request via WP-Cron and can overlap itself under concurrent traffic. Each run emailed the payments it created with no record that a notice had gone out, so two overlapping runs could send a payer two identical "Payment due" emails for one charge — read by families as being billed twice, though only one row exists. Stamp us_payments.notice_sent_at atomically before emailing: the scan now claims each payment with a conditional UPDATE ... WHERE notice_sent_at IS NULL and only notices, credits and batches the rows it won. A competing run finds them claimed and stays quiet, so exactly one notice is sent regardless of how the scan is triggered. A one-time backfill stamps existing scheduled rows on upgrade so already-noticed charges are not re-emailed. Co-authored-by: anthropic/claude-opus-4-8	2026-09-17 13:19:25 -03:00