Tuition and registration payments
Collect tuition, enrollment fees, and seasonal registrations without committing to heavyweight studio software first
Flint gives studios, lesson businesses, tutoring operators, and youth programs a cleaner payment layer for recurring tuition plus one-time registration, recital, camp, and family-managed checkout. Start with hosted payment flows and structured billing before you take on a full parent portal build or vertical suite migration.
Payment Mix
Recurring tuition
Subscription plans for monthly or term-based billing.
One-time fees
Enrollment, recital, camp, uniforms, books, and testing.
One payment layer
Hosted links, custom fields, clean orders, and refund history.
35,649
Instruction Businesses
Combined U.S. fine-arts schools and sports or recreation instruction establishments in 2022.
2022 CensusRecurring + One-Time
Billing Mix
Operators usually need monthly tuition plus enrollment, recital, camp, merch, or event charges around it.
Parent-Managed
Checkout Pattern
The payer is often the parent or guardian, so hosted checkout matters even before a dedicated family portal exists.
The workflow problem
Tuition billing gets messy when recurring and one-time payments live in different tools
Most operators do not need a giant education platform on day one. They need a cleaner way to charge recurring tuition, collect registration money, and stop stitching together payments, student details, and refund history by hand.
The old way
With Flint
How it works
One payment workflow for monthly tuition and seasonal registration
The core idea is simple: use the recurring billing surface when the cadence is predictable, use hosted checkout when the charge is one-time, and keep the operational trail in one place.
Create the recurring tuition plan or one-time registration page
Use subscription plans for predictable tuition, or create a hosted payment link with line items when the charge is an enrollment fee, recital registration, camp payment, or other one-time collection.
Add the information you need at checkout
Collect parent email plus custom fields like student name, program, level, shirt size, allergy notes, class day, or any other detail staff needs after payment.
Share the hosted link wherever enrollment happens
Drop it into email, text, registration forms, your site, or onboarding messages so parents can complete payment from any device without a custom portal build first.
Manage recurring billing and one-off follow-up cleanly
Tuition renewals, one-time fees, and refunds all stay attached to Flint orders and payment records instead of disappearing into disconnected systems.
What you get
Payment primitives that match how programs actually charge families
Flint already exposes the recurring billing, hosted checkout, event-mode payment links, and custom field controls this workflow depends on.
Recurring tuition with subscriptions
Use subscription plans and recurring billing when monthly tuition follows a predictable cadence and you want lifecycle handling instead of manual rebilling.
Hosted pages for enrollment and registration fees
Publish one-time payment links for signup fees, annual registration, exam prep packages, summer intensives, or other non-recurring charges.
Custom checkout fields
Collect student name, class level, instrument, shirt size, emergency contact notes, or other structured information directly at checkout.
Parent-managed checkout
The buyer is often the parent or guardian. Flint's hosted checkout fits that reality without forcing you to build account management before the billing workflow is proven.
Seasonal registration spikes
Handle recital entries, showcases, camps, intensives, testing dates, and workshops without spinning up separate payment tooling every time the calendar changes.
Event-mode registration when seats or tickets matter
Flint payment links already support event settings like date, location, ticket prefix, quantity caps, and ticket emails for recital or showcase-style flows.
Uniforms, books, and add-ons
Use line items for merchandise and operational extras so payments stay itemized instead of being flattened into one generic charge.
Refunds tied to the original order
When support needs to reverse a fee or adjust a payment, refunds stay attached to the order history rather than requiring spreadsheet archaeology.
Common workflows
Built for the recurring-plus-registration pattern
This page is not just for one kind of operator. It maps to the same payment pattern across studios, tutoring businesses, performance programs, and youth instruction businesses.
Dance, music, art, and swim studios
Monthly tuition, annual registration, recital fees, costumes, and showcase tickets all fit the recurring-plus-one-time payment mix.
Tutoring and test prep
Charge monthly programs, enrollment fees, bootcamps, or prepaid session packs while keeping parent checkout simple.
Martial arts and youth programs
Collect tuition, belt testing fees, uniforms, clinics, and camp registrations without forcing operators into heavyweight vertical software immediately.
Camps, intensives, and seasonal programs
One-time hosted checkout is often the right answer for summer sessions, holiday camps, and limited-run specialty programming.
Recitals, showcases, and performance extras
Use event-style payment pages when attendance counts, dates, locations, and ticket-style confirmation need to show up on the payment flow.
Enrollment workflows that still need details
Capture the operational context that matters after payment instead of collecting money first and then chasing the missing information later.
Built on real product surfaces
This page maps to the current docs, dashboard, and API model
Flint already documents subscription plans, subscriptions, subscription payment links, hosted payment links, custom fields, event mode, and refund flows. The dashboard already exposes event settings and custom field controls for payment links. This page is describing a real operating surface, not a speculative future workflow.
Recurring tuition signup
tuition-signup.ts
const plan = await flint.subscriptionPlans.create({
name: "Youth Ballet Monthly",
billingInterval: "MONTHLY",
currency: "USD",
lineItems: [
{
name: "Youth Ballet Tuition",
quantity: 1,
unitPriceMoney: { amount: 14500, currency: "USD" },
},
],
});
const link = await flint.paymentLinks.create({
name: "Youth Ballet Signup",
planId: plan.id,
customer: { requireEmail: true },
metadata: {
program: "youth_ballet",
season: "fall_2026",
},
});Registration or recital checkout
registration-link.ts
const link = await flint.paymentLinks.create({
name: "Spring Recital Registration",
mode: "EVENT",
lineItems: [
{
name: "Performer Registration",
amountMoney: { amount: 6500, currency: "USD" },
quantity: 1,
},
{
name: "T-Shirt",
amountMoney: { amount: 2500, currency: "USD" },
quantity: 1,
},
],
customFields: [
{ key: "student_name", label: "Student Name", type: "TEXT", isRequired: true },
{
key: "class_level",
label: "Class Level",
type: "DROPDOWN",
isRequired: true,
options: ["Primary", "Level 1", "Level 2"],
},
],
eventConfig: {
eventDate: "2026-05-16T18:00:00Z",
location: "Civic Center Auditorium",
maxTotalQuantity: 300,
ticketPrefix: "REC-",
sendTicketEmails: true,
},
});FAQ
Questions teams usually ask before changing the payment workflow
The main decision is not whether you need every piece of vertical software immediately. It is whether the payment flow itself can become cleaner today.
Should tuition use recurring billing or payment links?
Use recurring billing when the amount and cadence are predictable month to month. Use hosted payment links or checkout when the charge is one-time, seasonal, or tied to a specific enrollment or registration event.
Can this work before we build a parent portal?
Yes. That is the point. Start with hosted payment flows first, prove the tuition and registration workflow, and only add a broader family portal if the business genuinely needs it later.
What information can we collect during checkout?
Flint payment links support custom fields, so you can collect details like student name, program, class level, shirt size, or other operational information while payment is happening.
Why does order structure matter for studios and programs?
Because tuition is rarely the only charge. Once enrollment fees, recital payments, camp registration, merchandise, or refunds enter the picture, a structured order history is cleaner than isolated charges with no shared context.
Keep exploring
Follow the next surface that matches your team
The right next click depends on whether you want the operator-facing industry page, the core recurring-billing product page, or the underlying API documentation.
Studios & Lessons
The vertical page for tuition, family billing, recitals, and program registrations.
Tutoring & Test Prep
The vertical page for enrollment fees, session packs, recurring plans, and parent-managed checkout.
Youth Sports
Another parent-managed vertical where registrations, camps, and seasonal fees overlap with recurring payments.
Subscription API
The core Flint recurring-billing page behind predictable monthly tuition collection.
Subscription Billing Guide
The developer guide for plans, subscriptions, payment methods, and lifecycle events.
Payment Links API
The API surface for hosted payment links, custom fields, event mode, and shareable checkout URLs.