How Outdoor Lesson Schools Handle Payments: Pay Now, Pay Later, or Deposit

How Outdoor Lesson Schools Handle Payments: Pay Now, Pay Later, or Deposit

A customer books a lesson. They picked a date, an instructor, maybe a location. Now the real question shows up: do you take payment right now, mark them as pay-later, or collect a deposit and let them settle the rest on lesson day?

All three models work. Different schools pick different approaches depending on whether they sell multi-day packages, whether they run mostly walk-ins, whether weather forces half their lessons to reschedule, or whether their customers are tourists who will disappear after one lesson.

The confusion starts when schools try to build those three workflows inside tools that only understand one. A generic appointment calendar assumes you take payment every time, so marking a lesson as needs-to-pay ends up living in a spreadsheet note. A Shopify site assumes everything is pay-up-front, so tracking who still owes a balance becomes a side conversation. A check-in kiosk that cannot collect partial payment forces you to either take the whole amount or skip payment entirely.

Outdoor lesson software that actually handles scheduling handles payment timing as part of the booking record, not a workaround you bolt on later. The lesson knows whether the customer paid, whether they owe a balance, whether they left a deposit, and what happens if they cancel or reschedule before the window closes.

This guide explains how the three models work, when to use each one, and how lesson scheduling software keeps payment status on the same record as the instructor, the gear, and the time slot.

Table of Contents

1. Three Payment Models That All Work

2. Pay in Full at Booking

3. Pay Later, Mark Needs-to-Pay

4. Deposit Now, Balance at Lesson

5. How Outdoor Lesson Software Handles All Three

6. Connecting Stripe Without Becoming a Payment Processor

7. Payment and Weather Don't Cancel the Same Way

8. What Happens to Payment When a Lesson Gets Rescheduled

9. Refunds, Partial Refunds, and Store Credit

10. Gift Cards and Packages Complicate the Math

11. Payment Timing Is a Setting, Not a Platform

12. Common Payment Mistakes and How to Fix Them

13. FAQ

Three Payment Models That All Work

Most outdoor schools land on one of three approaches, and the choice usually reflects how predictable their operation is, not how trustworthy their customers are.

Pay in full at booking. Customer enters their card or checks out through Shopify, the full lesson price is collected immediately, and the booking is confirmed. This works well for high-demand schools, tourist-heavy locations, or any operation where a customer booking a slot means someone else cannot have it.

Pay later. Booking is confirmed, payment happens when the customer arrives or after the lesson. The school marks the booking as needs-to-pay, and the lesson goes on the calendar without a completed transaction. This is common when weather frequently forces reschedules, when most customers are repeat clients, or when the school sells multi-lesson packages billed monthly.

Deposit now, balance later. Customer pays a portion up front, the rest is due on lesson day. Deposits create commitment without taking the full amount before weather is certain. Schools use this model to reduce no-shows while keeping flexibility for the customer if conditions fall apart.

None of these is universally better. A kiteboarding school on the Oregon coast where half the lessons move because of wind will lean toward pay-later or deposit. A fishing charter in the Keys that books out weeks in advance will lean toward pay-in-full. A climbing guide service that runs the same multi-pitch route every Saturday will probably take full payment because the lesson rarely moves.

The operational problem shows up when your scheduling tool only understands one model and you need all three. A customer books a private. You want deposit. The widget says pay-in-full or nothing. Now you are collecting payment outside the system, updating a spreadsheet, and your actual revenue lives somewhere other than your lesson schedule.

Outdoor lesson software should store payment status on the booking itself so the schedule reflects whether the customer paid, whether they owe a balance, and what that balance actually is.

Pay in Full at Booking

Full payment at booking means the transaction completes the moment the customer confirms the lesson. The card processes, the receipt goes out, the lesson shows on the calendar as paid, and the customer cannot later claim they never agreed to the price.

This model works best when the lesson has a high likelihood of actually running and when the school needs to block capacity. A sailing lesson on a lake in July is probably happening. A horseback trail ride at 9 a.m. on a Thursday is probably happening. A beginner rock-climbing session at an indoor wall is definitely happening. Full payment makes sense because the slot is real, the instructor is committed, and the customer is unlikely to disappear.

The trade-off is refund pressure. If weather forces a cancel or the customer gets sick, they already paid, so now the conversation shifts to whether they get a refund, a reschedule, or store credit. That is fine if your cancellation policy is clear and the customer read it, but it becomes friction if the policy was buried in the confirmation email and the customer assumes a refund is automatic.

Full payment also reduces no-shows. A customer who handed over $200 is more likely to show up than a customer who marked a calendar date with no financial commitment. That behavior shift is real and measurable, even if it feels slightly cynical to say it out loud. For outdoor lesson schools where instructor time and equipment availability are the constraints, reducing no-shows by 30 percent is worth the added refund-policy conversations.

The implementation is straightforward when the school has connected Stripe. Seshana sends the customer to Stripe Checkout, the payment processes on the school's connected account, the booking confirmation goes out, and the lesson appears on the schedule with payment recorded. No manual ledger update, no marking it paid later, no second system tracking what actually cleared.

Pay Later, Mark Needs-to-Pay

Pay-later means the booking is confirmed but the transaction has not happened yet. The customer is on the calendar, the instructor is assigned, the gear is blocked, and payment will happen at some point between now and the end of the lesson.

This model shows up most often in three scenarios: the school sells packages and bills monthly, the school runs mostly repeat customers who settle accounts in person, or the weather makes taking money up front feel premature because half the lessons are going to reschedule anyway.

A mountain bike guide service in Colorado books a beginner clinic for Saturday. The forecast on Monday shows possible thunderstorms. Taking $400 from a family of four on Monday, knowing there is a decent chance the lesson moves to Sunday or the following weekend, creates unnecessary refund admin. Easier to confirm the booking, mark it pay-later, and settle payment once the weather window is actually clear.

The risk is no-shows. A lesson with no payment attached has less commitment than one where the customer already handed over a card. Some customers will ghost, some will forget, and some will assume that because they did not pay, the booking was not real. Pay-later works when the school has a relationship with the customer, a clear follow-up process, and a cancellation policy the customer actually understands.

Outdoor lesson software handles this by marking the booking as needs-to-pay. The lesson is on the calendar, the instructor sees it, but the payment status is clearly unfulfilled. The school can collect payment later through Stripe, cash, check, or an external processor, then mark the lesson paid inside the schedule so the record is complete. The schedule does not assume payment happened just because the lesson ran; it tracks payment as a separate state.

For the broader operational picture around scheduling, weather decisions, and no-show prevention, see The Complete Guide to Running an Outdoor Lesson Business. That guide covers how lesson confirmations, reminders, and cancellation policies reduce the risks that come with pay-later models.

Deposit Now, Balance at Lesson

Deposit payment splits the transaction. The customer pays a portion when they book, the rest is due on lesson day, and the school gets commitment without taking the full amount before the weather window is certain.

A $250 kiteboarding lesson might ask for a $75 deposit at booking. The customer puts down enough money that disappearing costs them something, but not so much that a weather cancel creates a big refund conversation. The remaining $175 is due when the customer shows up, either by card, cash, or however the school prefers to settle day-of payment.

Deposits land somewhere between pay-in-full and pay-later in terms of both commitment and operational overhead. They reduce no-shows more effectively than pay-later, but they create two transactions instead of one. The school has to track what was paid, what is still owed, and what happens to the deposit if the lesson cancels or reschedules.

The typical deposit structure is a fixed amount or a percentage. Fifty dollars, $75, $100 as a flat deposit regardless of lesson price. Or 25 percent, 30 percent, half the total as a percentage. Fixed amounts are easier to communicate. Percentages scale better across different lesson types, but they require the customer to do math, and some customers will round wrong or assume the deposit was higher than it actually was.

Most schools make the deposit non-refundable past a certain cancellation window. Cancel three days out, you get the deposit back. Cancel the morning of, you lose it. Cancel because of weather the school called off, you keep it as credit toward a reschedule. The exact policy matters less than making sure the customer knows the policy before they pay the deposit, because deposit disputes are more common than full-payment disputes. A customer who paid $75 and then could not make the lesson will argue harder about getting that $75 back than a customer who paid $250 up front, even though the latter is a bigger amount. The psychology is that a deposit feels conditional, so customers expect different refund rules.

Seshana handles deposit math by storing both the amount paid and the amount still owed on the booking. The schedule shows the lesson as partially paid, the outstanding balance is visible to the admin and the instructor, and the school can collect the rest through Stripe, cash, or another method when the customer arrives. If the lesson reschedules, the deposit amount stays attached to the new booking so the school does not have to re-enter it manually.

How Outdoor Lesson Software Handles All Three

The reason outdoor lesson software exists as a category separate from generic booking tools is that outdoor lessons are not appointments. An appointment is a person and a time. A lesson is an instructor, a piece of equipment, a location, a customer who may or may not have paid, a waiver that may or may not be signed, and a weather forecast that may or may not cooperate. Payment status is one attribute on a record that has a dozen others, and all of them need to line up for the lesson to actually run.

Generic booking platforms treat payment as a boolean: paid or not paid. Outdoor lesson software treats it as a state with multiple outcomes: paid in full, needs to pay, partially paid with a known balance, paid through a gift card, paid via Shopify and awaiting schedule placement, refunded, credited, or disputed.

Seshana stores the payment timing setting at the organization level and the payment status on each individual booking. The school sets a default (pay-in-full, deposit, or pay-later) in settings, and the booking widget, the public calendar, the kiosk, and staff-created bookings all respect that default unless overridden. An admin creating a lesson for a walk-in can mark it pay-later even if the default is pay-in-full. A customer booking through the widget will hit Stripe Checkout if the school has payments turned on and the default is pay-in-full.

When a lesson is created, the record includes who is teaching it, where it is happening, what equipment is assigned, and whether the customer paid. The schedule does not assume. If the lesson was created through the booking widget and Stripe Checkout completed, the payment status updates automatically. If the admin created the lesson over the phone and told the customer to pay on arrival, the status is needs-to-pay and stays that way until someone marks it paid or processes a transaction.

This means the daily schedule is also the payment ledger. An instructor looking at their afternoon lessons can see which customers still owe money. An admin running a revenue report can filter by payment status and know exactly which bookings are paid, which are pending, and which were cancelled before payment ever happened. The same record that tells you where to be and who to teach also tells you whether you have been paid for it.

Connecting Stripe Without Becoming a Payment Processor

Schools worry that accepting payments inside scheduling software means the software company is handling their money, holding their funds, or inserting themselves into the transaction. That is not how Stripe Connect works, and it is worth explaining because the confusion stops some schools from turning payments on even when it would simplify their operation.

Seshana does not process payments. Stripe does. The school connects their own Stripe account, and every transaction runs on that account. The money goes directly from the customer's card to the school's Stripe balance, Stripe handles the banking and compliance, and the school controls refunds, payouts, and disputes from their Stripe dashboard. Seshana never holds funds, never sees the full card number, and never acts as the payment processor.

What Seshana does is create the Stripe Checkout session, pass the booking details to Stripe, and update the lesson record when Stripe confirms the payment went through. The school gets a payment processor they already trust, the customer gets a checkout flow that works, and the lesson schedule reflects payment status without anyone building a second ledger outside the product.

The school still owns the Stripe account, still controls the payout schedule, and still handles any disputes or chargebacks through Stripe's tools. The only thing that changed is the lesson booking now includes a payment link instead of the school manually sending a PayPal request or writing down a card number on a clipboard.

Schools that already use Shopify can keep using it. Seshana supports a Shopify booking mode where the customer checks out on the school's Shopify site, Shopify processes the payment, and a webhook tells Seshana to create the booking. The lesson appears on the schedule as paid, even though Seshana never touched the transaction. This works well for schools that want their full e-commerce catalog and lesson booking to live in one checkout flow.

For schools that prefer to collect payment in person, nothing forces them to connect Stripe. The booking widget can run in pay-later mode, staff-created lessons default to needs-to-pay, and the school settles every transaction with a square reader, a cash box, or their existing merchant account. The schedule still tracks payment status; it just does not automate the transaction.

Cost and product questions belong on the FAQ and Pricing pages. Payment setup is part of Getting Started, not something that requires a support call to configure.

Payment and Weather Don't Cancel the Same Way

A lesson cancels for two completely different reasons: the customer cancelled, or the weather made the lesson unsafe. Those sound similar, but the payment implications are opposite.

Customer cancels three days before a kiteboarding lesson. Refund policy says 48 hours, so they are outside the window. School keeps the payment or converts it to credit. Clear outcome, annoying conversation, but the rule was stated up front.

Weather cancels the same lesson the night before because the wind forecast went from 18 knots to 35 knots and teaching a beginner in that is a bad idea. School calls it off. Customer did not do anything wrong, the school made the safety call, and now the payment needs to be handled. Most schools either reschedule with no penalty or issue a full refund. A few convert it to credit with no expiration. Almost none keep the money, because charging a customer for a lesson the school cancelled creates the kind of review you do not recover from.

Outdoor lesson software that understands weather handles this by separating cancellation reason from payment status. The lesson status becomes cancelled, but the payment status can go to refunded, credited, or transferred to a rescheduled booking depending on what the school decides. A generic booking tool assumes cancel means refund, which is wrong half the time in outdoor lesson operations.

Seshana tracks both the lesson status and the payment status separately. A school can mark a lesson as cancelled, choose whether to refund or credit, and reschedule the customer without creating a second booking that looks like a new sale. The original payment can move to the new date, the refund can process through Stripe automatically, or the school can issue credit that applies to the next booking. The schedule reflects what actually happened instead of forcing the school to reverse-engineer it from a payment processor dashboard and a calendar.

For the tactical guide to weather decisions, cancellation workflows, and rescheduling processes, see Outdoor Lesson Scheduling: The Complete Guide. That article goes deeper on building a weather cancellation process that does not create payment chaos.

What Happens to Payment When a Lesson Gets Rescheduled

Rescheduling a lesson is one operation. Handling the payment for that rescheduled lesson is a separate decision, and most scheduling tools do not connect the two.

A customer books a sailing lesson for Saturday, pays in full, then calls Thursday to move it to Sunday because their flight changed. The lesson moves. Does the payment move with it, or does the school refund Saturday and re-charge for Sunday? If the policy says no refunds inside 48 hours but the customer is not asking for a refund, just a date change, does the policy still apply?

Most schools treat a reschedule-before-cancellation-window as free. The payment transfers to the new date, no refund, no second charge, just an updated calendar entry. The operational complexity is making sure the new lesson shows the original payment instead of creating a second transaction or losing the payment record entirely.

Outdoor lesson software should carry the payment forward when a lesson reschedules. Seshana does this by linking the original booking to the new one. The new lesson inherits the payment status, the customer does not get double-charged, and the revenue report does not count the same $250 twice. If the reschedule happens because of weather and the school offers a refund instead, the original payment can be reversed and the new booking can be created fresh. Either way, the schedule reflects the actual financial state without requiring a separate ledger reconciliation.

Partial reschedules complicate the math. A three-hour lesson runs for one hour, then wind dies. School calls it incomplete, offers a one-hour makeup. Customer already paid $300. Do they pay again for the makeup, or does the $300 cover both sessions? Most schools credit the remaining time and mark the makeup as already paid. The payment record needs to split across two bookings, which is impossible in a tool that treats each appointment as a standalone transaction.

Seshana tracks remaining minutes on incomplete lessons and can create a linked makeup session with the balance already applied. The original payment decreases by the amount attributed to the completed portion, the new session shows the remaining balance as already paid, and the school does not have to manually adjust two separate invoices to make the numbers add up.

Refunds, Partial Refunds, and Store Credit

Refunds are straightforward when the entire lesson cancels and the school agrees to return the money. Click refund, Stripe reverses the charge, the customer sees the credit in three to five days, and the booking status updates to reflect the refund.

Partial refunds happen when a lesson ran but something went wrong. A two-hour lesson only got 90 minutes because the boat had engine trouble. A group lesson was supposed to be six people, only two showed up, and the price-per-person was supposed to drop. A customer paid for a private, got paired with another student without their knowledge, and the school agrees to refund the difference. The original charge was $250. The refund is $100. The net payment is $150, and the lesson record needs to reflect that instead of showing $250 paid and $100 refunded in two separate places.

Outdoor lesson software should allow partial refunds without orphaning the payment record. Seshana processes partial refunds through Stripe and updates the lesson to show the adjusted total. The revenue report reflects what the school actually kept, not what was charged before the refund.

Store credit is a financial liability. A customer pays $300 for a lesson. Lesson cancels. School offers credit instead of a refund. That $300 is now owed to the customer in the form of a future lesson, and if the school does not track it, the customer will call six months later expecting to book a free lesson and the school will have no record of the agreement. Store credit has to live somewhere other than memory.

Seshana tracks credit on the customer profile. An admin can issue credit manually, credit can be generated automatically from a refund-as-credit policy, and the credit balance applies to future bookings when the customer books again. The customer sees their available credit when they log in or call to book, the school sees it when creating a lesson for that customer, and the revenue report separates cash transactions from credit redemptions so the numbers do not double-count.

Gift cards add another layer. A customer buys a $500 gift card, uses $250 of it on a lesson, and has $250 remaining. That remaining balance is store credit, but it came from a sale rather than a refund. The accounting has to track both the original gift card sale and the redemption without treating the redemption as new revenue. Seshana handles this by storing gift card balances separately and applying them at checkout the same way promotional credit applies. The lesson shows as paid, the gift card balance decreases, and the revenue report knows the difference between a $250 cash lesson and a $250 gift-card-redeemed lesson.

Gift Cards and Packages Complicate the Math

A customer books a lesson and pays $200. Revenue is $200. A customer buys a $500 gift card and later redeems $200 of it for a lesson. Revenue is still $500, but it happened at gift card purchase, not lesson redemption. The lesson is not new revenue; it is fulfillment of an already-paid liability. The schedule has to know the difference or the school will think they made $700 when they actually made $500.

Packages create the same problem. A customer pays $1,200 for a ten-lesson package at $120 per lesson. Each lesson they take is not $120 in new revenue; it is $120 drawn from the $1,200 they already paid. The schedule has to track package usage separately from cash transactions or the revenue report will overstate earnings by counting the same money twice.

Seshana tracks gift cards and hour-based packages as customer credit. When a customer redeems credit for a lesson, the booking shows as paid but the revenue report categorizes it as credit fulfillment rather than a new sale. Schools can see total sales, total redemptions, and outstanding credit liability in one report instead of piecing it together from three different tools.

The harder problem is partial redemption. A lesson costs $250. The customer has $300 in credit. Simple: apply $250, leave $50. But what if the lesson costs $350 and the customer only has $300 in credit? Does the booking widget allow them to pay the $50 difference by card, or does it force them to either use the credit on a cheaper lesson or pay the full $350 separately? Most schools want the split payment option, which means the checkout flow has to handle both credit and card in a single transaction.

Seshana allows split payments when the school has Stripe connected. The widget calculates the credit available, applies it to the total, and sends the customer to Stripe Checkout for the remaining balance. The lesson is marked paid when both the credit redemption and the card charge complete. If the card charge fails, the credit does not apply and the booking does not confirm. No partial state where the customer burned $300 in credit but the lesson never got scheduled.

Payment Timing Is a Setting, Not a Platform

Some schools think choosing pay-in-full versus pay-later is a permanent decision, like picking Stripe over Square or Shopify over WooCommerce. It is not. It is a setting that can change week to week if the operation needs it to.

A sailing school in the Pacific Northwest runs group classes all summer. Pay-in-full at booking makes sense because the classes fill up and the weather is predictable. Same school offers private lessons in the spring when conditions are rougher. Pay-later or deposit makes more sense because half the privates reschedule. The school should be able to set one default for group classes and a different default for privates without rebuilding their entire checkout flow.

Seshana lets schools configure payment timing separately for different lesson types or leave it as a global default. A kiteboarding school can set beginner lessons to deposit-required and advanced clinics to pay-in-full. A fishing charter can set nearshore trips to pay-later and offshore charters to pay-in-full because offshore books out further in advance and costs three times as much. The booking widget and the schedule both respect those settings without requiring separate configurations for every lesson.

Settings live in one place, not scattered across integrations. Payment timing, cancellation windows, refund policies, and deposit amounts are all configured under Settings in the Seshana admin. Changes apply immediately to new bookings. Existing bookings keep the payment terms they were created under, so a customer who booked under a 48-hour cancellation policy does not suddenly face a 72-hour policy because the school changed the setting after they paid.

Some schools will want pay-later for everything until they turn on Stripe. Others will want Stripe connected from day one and pay-in-full as the default. A few will toggle between the two depending on season or local event calendars. Outdoor lesson software should treat payment timing as a dial the school turns, not a track they commit to for the life of the business.

Common Payment Mistakes and How to Fix Them

Charging for lessons that did not run because of weather. This destroys trust faster than any other mistake. If the school cancelled for safety, the customer gets a refund or a free reschedule, not a fight about the cancellation policy. Build this into your refund workflow so instructors and admins do not have to guess.

Losing track of who still owes money. Pay-later only works if the schedule shows payment status clearly and the school follows up. If an instructor arrives at a lesson and has no idea whether the customer already paid, the operation is broken. The schedule is the ledger. Make sure payment status is visible on every lesson.

Taking deposits without explaining what happens to them. A customer pays a $75 deposit and assumes it is fully refundable. The school assumes it is non-refundable past 48 hours. Nobody wrote the rule down. The conflict happens when the customer cancels at 36 hours and expects $75 back. Deposit policies belong in the booking confirmation email, not in a terms PDF nobody reads.

Running two separate ledgers for revenue and scheduling. Quickbooks says the school made $8,000 last week. The schedule says 40 lessons at an average of $220 means $8,800. Where did the $800 go? Probably refunds, credits, or lessons that were created but never paid. If the schedule does not track payment, the school is always reconciling two sources of truth and one of them is always wrong.

Allowing customers to book without any payment commitment when no-shows are already a problem. Pay-later is not a good default for schools with high no-show rates unless the school is also sending confirmation requests, reminders, and follow-ups. If the booking has no financial commitment and no communication workflow, the no-show rate will stay high. For tactics on reducing no-shows, see How to Reduce No-Shows for Outdoor Lessons: A Practical Guide.

Forcing customers to pay the full amount before the weather window is certain. This creates refund admin and frustrates customers who know the lesson might not run. If weather is unpredictable, deposits or pay-later reduce friction without eliminating commitment. Schools in high-wind, high-weather-volatility locations should default to deposits unless demand is so high that full payment makes sense regardless.

FAQ

Can I use Seshana without connecting Stripe? Yes. The booking widget can run in pay-later mode, where customers book and the school collects payment in person or through another processor. The schedule still tracks payment status; it just does not automate the transaction.

What happens to payment if a lesson reschedules because of weather? The payment status can transfer to the new lesson, be refunded, or be converted to credit, depending on what the school decides. The schedule links the original booking to the rescheduled one so the payment does not get lost or double-counted.

Can customers pay a deposit at booking and the rest on lesson day? Yes. Deposit amounts can be set as a fixed dollar amount or a percentage of the lesson price. The schedule tracks the deposit and the remaining balance so the instructor knows what the customer still owes when they arrive.

Does Seshana take a cut of payments? No. Stripe processes the payment on the school's connected account, and the school keeps the full amount minus Stripe's standard processing fee. Seshana does not take a percentage of transactions.

Can I set different payment rules for different lesson types? Yes. Payment timing, deposit amounts, and cancellation policies can be configured per lesson type or as a global default. A school can require full payment for one type of lesson and allow pay-later for another.

What happens if a customer books through Shopify? Shopify processes the payment, sends a webhook to Seshana, and the lesson appears on the schedule as paid. The school handles the transaction entirely through Shopify, and Seshana just creates the booking record.

Can I issue partial refunds? Yes. Partial refunds process through Stripe and update the lesson to reflect the adjusted total. The revenue report shows what the school actually kept after the refund.

How do gift cards and packages work with payment tracking? Gift cards and hour-based packages are tracked as customer credit. When redeemed, the lesson is marked paid but categorized as credit fulfillment rather than new revenue. The schedule separates cash sales from credit redemptions so the numbers do not double-count.

Can customers pay part with credit and part by card? Yes, when Stripe is connected. The checkout applies available credit first and charges the remaining balance to the customer's card in a single transaction.

What if I want to take payment in person even though Stripe is connected? Staff-created lessons can be marked pay-later regardless of the school's default payment setting. The instructor collects payment on arrival, then marks the lesson paid in the schedule.