Step 01
Separate the club money flow from the software invoice
The member pays the club through Stripe. Stripe charges processing fees. Lobby invoices software separately and does not take a booking percentage.
Show Stripe status beside the booking, class, membership, or event record.
Keep processor fees in Stripe reporting rather than blending them into software revenue.
Make the Lobby fee model visible on pricing and contracts before rollout.
Step 02
Make every paid booking auditable
A finance-friendly booking row needs more than an amount. It needs enough identifiers to answer what was sold, how it was paid, and whether it has moved or refunded.
Booking ID, court or class, member, amount, currency, and tax label
Stripe checkout session or payment intent reference
Payment status, refund status, payout date, and payment method
Operator action history for moves, cancellations, and manual adjustments
Step 03
Run a short daily reconciliation check
The daily check should be boring: paid bookings match Stripe payments, refunds are intentional, pending payments are visible, and manual overrides are named.
Filter yesterday and today by paid, pending, failed, and refunded states
Compare gross booking totals with Stripe activity for the same window
Review refunds against cancellation rules and staff notes
Export the report before month-end cleanup changes the context
Step 04
Keep exceptions explicit
Cash payments, bank transfers, waived fees, and source-system imports can all exist, but they should not masquerade as card-settled Stripe revenue.
Tag offline payment methods separately from Stripe payments.
Keep imported historical payments reference-only unless the processor IDs are intact.
Expose failed and pending states to staff instead of hiding them from the booking desk.