There are two payment relationships

The first relationship is between the software platform and the driving school. That is the monthly subscription for the tenant’s plan. The second relationship is between the driving school and its students or parents. That is the payment for a package, deposit, balance, or lesson service.

Mixing those two flows creates confusing reporting and risky assumptions. The platform subscription should live in subscription records. Student payments should live in tenant-scoped payment records tied to the student, enrollment, package, and connected account.

Subscription records for the tenant plan Connected account status per tenant Payment records tied to student and enrollment

Hosted onboarding keeps sensitive collection out of the app

For a SaaS serving small schools, Stripe-hosted Connect onboarding is usually the practical early path. The school completes required identity and payout steps through Stripe, while the application stores the connected account ID and status information.

The dashboard should show whether onboarding is incomplete, payments are enabled, payouts are enabled, or more information is required. It should not collect bank details directly or imply that a school can charge students before its payment setup is ready.

Charges enabled Payouts enabled Requirements currently due and past due

Payment state belongs next to the enrollment

When a family buys a package, staff need to understand the status from the student record. Was a deposit paid? Is there a remaining balance? Did the payment fail? Was a refund issued? Those details matter more to the front desk than raw payment-provider event names.

A good dashboard translates payment events into school-friendly states while still keeping the underlying identifiers for audit and support. That makes the system usable without hiding important information from the owner.

Unpaid Deposit paid Paid, partial, failed, or refunded

Do not charge students until payments are enabled

If Stripe Connect is not enabled for a school, the public enrollment flow should say online payments are not available and use the school’s configured offline instructions. That is better than showing a broken checkout path or silently pretending payment happened.

Software for Driving School keeps platform subscription billing separate from connected-account transactions. That makes the system easier to review before launch and reduces the chance that a subscription webhook accidentally changes a student payment record.

This separation also helps support. If a school asks about its monthly plan, staff can review subscription billing. If a parent asks about a lesson package payment, the school can review the student payment record. The two conversations stay clear.

Online payments disabled message Pay later or pay in person if enabled Separate webhook handling

Launch path

See how this works in the product

Choose a driving-school template, add packages and booking rules, preview the public site, and publish only when the school content is ready.