The shape of it
A household has a billing account. Charges are posted to it — a membership fee, a meet fee, a guest pass. Payments are recorded against it. The balance is the difference, and it is one number that every screen reads.
There is no second ledger. The treasurer's statement, the family's balance card and the front desk's verdict are the same number.
Card payments
Card payments run through Stripe. SwimWin does not hold your club's money and does not touch a card number — the card details go to Stripe, and SwimWin records what Stripe says happened.
Booked once, even when Stripe says it twice
Payment processors deliver the same event more than once. That is normal, it is documented behaviour, and a system that does not plan for it charges a family twice and produces a treasurer's report nobody trusts again.
SwimWin books a Stripe event exactly once. A repeated delivery of an event that has already been recorded is recognised and discarded rather than posted again.
Offline payments
Cash and bank transfer are first-class, not a workaround. Record the payment against the account and the balance, the statement and the gate verdict all update together. A club system that cannot record a bank transfer is a club system that produces two sets of books.
Proration
When a charge is calculated from a partial period, the basis is recorded with the charge. The question "why is this £64 and not £80" has an answer stored alongside the number, rather than being reconstructed from memory in October.
What is not built yet
- Families paying online. No card on file and no Pay button in the portal. Coming soon.
- Discount rules. See Discounts and credits.
- Payment receipt and payment failed emails. See Announcements.
- Reporting. See Reports.