Payment trust breaks fastest when studios communicate before verification is complete. This page covers how Classia represents Stripe readiness so you can make evidence-based decisions about go-live, reminders, and arrears conversations. It is written for UK operators balancing Direct Debit expectations, card fallback, and term-time pressure. Use it whenever the payment state feels unclear.
Lead with one real friction moment
A studio sends "online payments now live" to 120 families on Sunday. On Monday, several checkouts fail because card capability is still pending. Staff then spend two days apologising and collecting manually.
Use one consistent approach: do not message from assumption. Message from verified state.
The core states to read first
In account payment settings, Classia surfaces:
- onboarding state,
- card payments capability,
- transfers capability,
- requirement categories (past due, due now, pending verification, due later),
- disabled reason where present.
These are not decorative labels. They are operational signals.
How onboarding state is calculated
Account onboarding state is derived from Stripe-linked account data and requirement categories.
Typical progression:
- not started
- in progress
- pending verification
completedrestricted
restricted and pending verification are very different. Pending verification usually means review is in progress. Restricted means something is blocking normal payment operation.
Capability states and what they mean in practice
Card and transfer capabilities are normalised to:
activependinginactive
Practical interpretation:
- Card capability
active: card-based checkout pathways can proceed when other checks pass. - Card capability
pendingorinactive: card-required checkout should not be treated as live. - Transfer capability helps indicate payout readiness, not just collection readiness.
Example: pending card capability before term launch
A yoga studio finishes onboarding screens but capability remains pending. They delay payment launch message by 48 hours. Families receive one clear message when state turns active, avoiding false starts.
Requirement categories: what needs action now
Classia stores requirement categories from Stripe refresh:
- past due
- currently due
- pending verification
- due later
Use them as a response order:
- clear past due first,
- resolve currently due quickly,
- wait and monitor pending verification,
- schedule eventually due tasks before next busy cycle.
If disabled reason is present, treat it as blocking context until resolved.
Why webhook sync matters
Capability and requirement state should be refreshed by account-level webhook events such as:
account.updatedcapability.updated
Those events trigger account refresh and requirement rebuild. If you make decisions from stale memory instead of refreshed state, trust signals become unreliable.
Checkout gating behaviour to know
Checkout service validates provider readiness before creating payment checkout sessions.
If a payment path requires card capability and card capability is not active, checkout is blocked with a provider-not-ready style error.
This protects families from entering a broken checkout journey.
Example: card-or-direct-debit profile with inactive card capability
A studio uses a profile that permits card or Direct Debit. Card capability is inactive. Parent attempts checkout and receives a readiness block. Team updates communication and prioritises capability completion before retry.
Example: payout confusion during verification
Transfers capability is pending while card capability is active. Collections can proceed, but payout expectation needs clear explanation. Studio tells staff: "payments may process, payouts may still be pending review".
UK language for family communication
When parents ask "why not paid yet?", use precise terms:
- "due now" means payment due date has arrived and is still unpaid,
- "overdue" means payment remains outstanding past expected handling,
- "pending verification" means provider checks are still in progress.
For Direct Debit, avoid promising instant status changes on collection day. For card routes, explain that capability readiness still governs availability.
Pitfalls to avoid
- Announcing payment go-live when capability is pending.
- Treating onboarding completion screens as full operational readiness.
- Ignoring past-due requirement category because payouts look enabled in one moment.
- Explaining Direct Debit and card timing as if they behave identically.
- Troubleshooting checkout without first checking capability and disabled reason state.