Parents ask when Direct Debit leaves their account, one class has overdue items, and your admin has spotted a payment profile mismatch. This guide is built for that moment. It explains how Classia payments actually work in production, from Stripe Connect onboarding to due-item recovery, so you can run a term without guessing. The focus is UK class businesses where cash flow, safeguarding, and parent communication all matter at the same time.
The short version before we go deeper
Payments in Classia are built on five linked parts:
- Stripe Connect account readiness.
- Payment profile rules.
- Class-level pricing and profile assignment.
- Payment schedules and due items.
- Checkout, webhook updates, and offline reconciliation.
When one of these is weak, the other four feel noisy. When all five are explicit, week-to-week billing becomes calmer.
What "ready" looks like before you publish paid classes
A class can be published before billing is truly ready. That is where trouble starts. Use this launch gate instead.
Billing readiness gate:
- Stripe onboarding started and reviewed in Settings > Payments and Payouts.
- No unresolved past-due Stripe requirement blocking payouts.
- Card capability active if card checkout is part of your profile design.
- Payment profiles created and assigned to the right classes.
- Term and single-class prices set on each paid class.
If one item fails, hold publication for paid enrolment links until fixed.
How Classia billing behaves in real operations
Stripe onboarding and verification
Classia uses Stripe Connect Express. Onboarding state can move through not started, in progress, pending verification, completed, or restricted. Requirement categories like "past due" and "currently due" are not decorative. They affect whether checkout and payouts stay reliable.
Payment profiles as policy
Payment profiles define method and schedule rules, including:
- allowed methods (
card, Direct Debit, card or Direct Debit) - usage scope (full-term only, single-class only,
both) - deadline days
- installment anchor and count
- proration strategy
- fee handling and receipt policy
They are operational policy. Treat them like policy, not labels.
Schedule and due-item lifecycle
Once requests are approved with a valid profile, Classia builds or recalculates schedules and due items. Items move across due, paid, overdue, and void states. Schedule status then reflects whether there are overdue items, due items, or all paid.
Checkout and state updates
Checkout creation can be blocked if the provider account is not configured or required capability is missing. Payment state is finalized by webhook events. This is why manual assumptions like "it looked paid in checkout" should be avoided until status is confirmed in records.
UK payment language your team should standardise
Most billing stress in small studios is communication drift, not arithmetic.
Use clear UK wording:
- "Direct Debit instructions are submitted on Monday and usually show by Wednesday or Thursday."
- "Card payment confirms immediately if successful."
- "Bank transfer payments are recorded when funds arrive."
- "Overdue means the due date has passed and payment is still outstanding."
If your staff use this language consistently, parent queries are shorter and easier to resolve.
Weekly control rhythm for a busy studio
A practical rhythm for one owner plus one admin:
Monday (30-45 minutes)
- check Stripe status and any requirement changes
- check new due items and class-level concentrations
- check classes with increasing overdue totals
Mid-week (20-30 minutes)
- review offline payment entries for accuracy
- correct any misapplied or missing notes
- confirm support replies for payment-related parent messages
End of week (30 minutes)
- review arrears by class
- confirm next week communication list
- check whether any profile or pricing rules need correction
This rhythm is simple, but it prevents the "Friday backlog reconciliation" pattern.
Payment flow diagram (structured text asset hook)
Use this text to create a visual later.
- Step 1: enrolment request approved with active payment profile.
- Step 2: payer resolved (responsible adult, family adult, or participant fallback).
- Step 3: payment schedule created or recalculated for term or single class.
- Step 4: due items generated with coverage dates and line-item splits.
- Step 5: payer opens portal and starts checkout for next due date group.
- Step 6: Stripe checkout session created with method types from profile rules.
- Step 7: webhook events update payment and due-item status.
- Step 8: schedule status refreshed (active, overdue, completed).
- Step 9: if offline payment is recorded, due item is reconciled and credits or adjustments applied.
Exception branches:
- if card capability inactive and card is required, checkout is blocked.
- if no due items exist, checkout is blocked.
- if payment underpays an offline due item, adjustment due item is created.
- if payment overpays offline, credit balance is increased.
UK scenarios
Example: Dance school with 11 classes and mixed methods
The school uses Direct Debit for full-term plans and card for single-class bookings. One admin wrote clear scripts for payment timing. Parent payment emails dropped by about a third within six weeks.
Example: Martial arts club with late-term arrears spike
Three classes showed overdue growth after half term. They switched from ad hoc reminders to a fixed Wednesday arrears review and clear reason notes for each contact.
Overdue count reduced before the next billing cycle.
Safeguarding and trust in payment decisions
Payments are not separate from safeguarding in child-focused provision. The wrong payer contact, or unclear family linkage, creates both billing confusion and trust risk.
For under-18 participants:
- make sure payer context follows responsible adult and family records
- keep payment communication with the correct adult contact
- avoid sharing child-identifying payment details outside authorised account staff
Calm payment practice is part of trust practice.
What this is not designed for
This flow is not designed for storing raw card data, bypassing Stripe webhook state, or relying on informal notes outside the payment screens. It is also not designed for skipping payer clarity in child contexts just to move faster.
Related guides
- Stripe Connect onboarding and verification
- Payment profiles: Direct Debit and card
- Schedules, due items, arrears, and offline payments
- Enrolments and status management
- Payment clearance before attendance
- Troubleshooting payment checkout and verification
Related feature
FAQ
Should we onboard Stripe before building classes?
You can build classes first, but do not publish paid enrolment pathways until payment readiness checks are complete.
Can one class use both card and Direct Debit?
Yes, through a profile that allows both methods, if the account capabilities support that path.
Why do some checkouts fail even when a schedule exists?
Common causes are missing provider configuration, inactive required capability, cancelled schedule, or no currently due items.
How does credit balance affect checkout?
Credit balance is applied to due totals before checkout. If credit fully covers due items, payment can complete without cash collection.
What should we do first when arrears rise?
Review overdue items by class, verify communication, and confirm that profile and due-date rules still match delivery reality.
Is offline payment only for full amounts?
No. Offline recording supports exact payment, underpayment (with adjustment item), and overpayment (credit balance increase).
Which page should we read next?
Read Payment profiles: Direct Debit and card if your setup still feels inconsistent between class types.