Every school runs a fall fundraiser and a spring gala. Almost none of them run it through the same payment system that collects tuition, which usually means a separate donation form, a separate ticketing vendor, and a second Stripe-adjacent account nobody in the business office fully reconciles until year-end.
Bloomz Pay now runs both, on the same ledger as everything else.
Donations, minted like any other charge
A school launches a DonationCampaign with a goal, a designation, suggested amounts, and a visibility window. Any authenticated member can give any amount at or above the campaign’s floor, and the gift mints through the exact billing primitive Bloomz Pay already uses for one-time charges. That’s not a small implementation detail; it’s the whole point. A donor gets one receipt, in the same payment history as their tuition invoice, and their gift is automatically included on their year-end tax statement, no separate donor-management export for the business office to reconcile by hand.
Apptegy Givebacks does donation campaigns. What it doesn’t do is land the gift in the exact same billing engine, Stripe account, and payment history as a family’s tuition. Bloomz does, because Donations isn’t a bolted-on module, it’s an add-on capability of the Payments system that already exists.
Tickets, with capacity that actually holds
Event ticketing works the same way. A TicketedEvent references an existing calendar entry, so the event itself stays the single source of truth for when and where, and defines one or more price tiers, each with its own optional capacity. A family buys a ticket, which is an opaque token, never a URL, the same privacy pattern every Bloomz QR flow already follows.
Capacity tracking is atomic per tier, which matters more than it sounds like it should. A naive implementation checking “is this tier under capacity” without locking the specific array element can let a rush of concurrent purchases at on-sale time oversell a multi-tier event by matching one tier’s key against another tier’s sold count. Bloomz’s capacity claim is scoped to the exact tier being purchased, so a General Admission rush can’t silently eat into VIP capacity, or the reverse. Tickets have no waitlist in this release, a deliberate scope decision: a sold-out tier is sold out, cleanly, rather than half-solved with a waitlist that creates its own support burden.
Check-in your front desk already knows how to do
The part that actually saves a Friday night: check-in reuses the same opaque-token QR scanning already built for Dismissal pickup and Visitor Management sign-in. Staff scan a ticket exactly the way they already scan a pickup code or a visitor badge. A re-scan of an already-checked-in ticket succeeds quietly instead of throwing an error at a volunteer working the door at 6:45pm. Finalsite Forms Plus sells per-person tickets with seating; Bloomz sells them through the same scanning muscle memory your staff never had to learn twice.
A refund, whether issued in-app or from the Stripe dashboard directly, releases the seat back to inventory automatically. Both new donation and ticket-sales reports export the same way every other Bloomz Pay report already does, one click, one CSV.
One documented boundary
Recurring donations are captured, a donor can select monthly or yearly, and the first charge mints immediately, but automatic re-charging on that schedule isn’t wired in this release. That’s a real, disclosed limitation, not an oversight we’re hoping nobody notices: a recurring donor’s first gift processes normally, and scheduled re-billing is a near-term follow-up.
See Donations & Event Tickets on the Bloomz Pay page, available behind a district flag as part of Bloomz Pay on every tier.