You can run great classes and still struggle if payments are only half configured. This page covers how to complete and maintain Stripe Connect Express in Classia so checkout and payouts behave predictably. It is for studio owners and admins who need a practical checklist, not payment jargon. If your team is asking "are we live yet?" this is the page to follow.
Examples
A gymnastics studio in Manchester had published nine paid classes. Requests were approved, but card capability was still pending. Parents reached the payment step and hit errors. The studio then had to explain delays one family at a time.
The issue was not that Stripe was "broken". The issue was that onboarding status had not been treated as a launch gate.
What to complete in Settings before go-live
In Settings > Payments and Payouts, Classia gives you a status summary and requirement groups. Work from this page, not memory.
Core actions:
- start onboarding if state is not started
- continue onboarding if state is in progress or restricted
- review requirements by category
- verify capabilities and payouts flags before publishing paid flows
If setup looks complete but something still seems off, open the Express dashboard from Classia and recheck requirements.
Understanding onboarding states in plain terms
Not started
Stripe account is not set up yet for this provider.
In progress
Account exists, but required setup items are still incomplete.
Pending verification
Details were submitted and Stripe is reviewing some fields.
Completed
Setup path is complete enough for normal operation, subject to capability and requirement checks.
Restricted
A disabled reason or past-due requirement is currently limiting operations.
Do not treat these as abstract labels. They define what your team can promise families.
Requirement categories and what each one means
Classia groups Stripe requirements into practical categories.
Past due
Highest urgency. These can block payouts and degrade payment operations.
Due now
Must be completed promptly to avoid moving into restricted state.
Pending verification
Stripe is reviewing submitted evidence or data. Usually no immediate action unless requested.
Due later
Not immediately blocking, but should be planned before next peak enrolment period.
A simple rule works well: resolve past due first, due now second, then monitor pending verification.
Capability checks that affect checkout
Two capability areas matter most in day-to-day studio billing:
- card payments capability
- transfers capability
If your payment profile path requires card and card capability is not active, checkout will be blocked. This is a common source of "it worked in testing" confusion.
UK-specific onboarding habit that prevents delays
For UK providers, request bacs debit capability as part of setup where Direct Debit is part of your billing model. Then confirm your public and parent-facing language matches what is actually active.
Concrete script for staff:
- "Card payments are active now."
- "Direct Debit is available for the classes using that payment plan."
- "If verification is still pending, we will confirm timeline by email."
Avoid loose wording like "payments should work".
Weekly maintenance routine after go-live
Even complete onboarding is not "set and forget". Requirement states can change.
Use a short weekly check:
- open Settings > Payments and Payouts
- review new requirement items
- confirm onboarding state and capability indicators
- assign owner and deadline for any corrective action
This takes minutes and prevents emergency fixes on billing day.
Examples
Example: Dance school with 14 live classes and one part-time admin
They added a Monday 8:30am payment status check after seeing a surprise requirement in week three. That single habit reduced same-day payment disruption.
Example: Martial arts studio with 86 active students in pending verification
The team stopped promising immediate card availability while status was pending verification. They used clear parent messaging and avoided support churn.
Example: Swim school with 9 overdue items and restricted state mid-term
A past-due requirement triggered restrictions. They used the requirement list to assign one owner per item and restored normal state before next due cycle.
Related guides
- Payments and billing (UK)
- Payment profiles: Direct Debit and card
- Schedules, due items, arrears, and offline payments
- Troubleshooting payment checkout and verification
Avoid these slips
1. Treating "in progress" as launch-ready
Families experience failed payment attempts when setup is assumed complete too early.
2. Ignoring requirement categories for days
Small delays often become larger restrictions close to due dates.
3. Promising card checkout before card capability is active
This creates immediate trust issues with parents.
4. Assigning no owner for payment status checks
When ownership is vague, unresolved items sit until they become urgent.
5. Skipping Express dashboard follow-up
Some maintenance tasks are faster to resolve directly there.