Booking and payments software: what happens to the money after the slot is booked

A client books a 90-minute massage for $120 and pays a $30 deposit online. At the appointment she adds hot stones for $25. She owes $115 at the end. Two weeks later she cancels her follow-up session 30 hours before it starts, and your policy says she gets half back.

That's five money events on one customer in a fortnight. The question I'd ask of any booking and payments software is a boring one: where does each of those five things get written down, and can you find all of them from the booking?

If the honest answer is "the deposit is in the payment processor, the add-on is a line on an invoice in a different tool, the refund is in the processor again, and the link between them is my memory", the software takes bookings and payments. It doesn't take them together. That gap is what this article is about.

Five money events, one booking

Here is the fortnight above as a table. The middle column is what I see most often in small service businesses: a scheduler, a card processor, and something that produces invoices, glued together by a person.

None of the left column is impossible. People run businesses on it for years. The cost isn't the software fee, it's the half hour per week someone spends reconciling, and the refund that goes to the wrong card because two clients share a surname.

Square sells the pieces as separate products

Square is the obvious comparison because it ranks for this search and because it does both halves, so I read its pricing pages this month (October 2026) to see how it packages them.

On those pages, Appointments and Invoices are listed as separate products. Each is priced per location on the same three tiers: Free at $0, Plus at $49 a month, Premium at $149 a month. Online card payments are 3.3% + 30¢ on Free and 2.9% + 30¢ on Plus and Premium. Invoices can request a deposit with a later due date for the balance, split payment into milestones, and accept bank transfer (ACH) at 1%. Appointment deposits, prepayment and refunds are listed as booking features, and the cancellation policy with no-show fees sits under the paid tier.

That is a perfectly sensible way to sell software to a business that already has a Square reader on the counter. What I couldn't tell from the pages is whether an invoice and an appointment share a record in the dashboard, or whether they're joined only by the customer profile. I didn't open a paid account to test it, so treat that as unchecked. If you're on Square now, it's the one thing I'd click through before deciding anything: book a test appointment with a deposit, add an extra, invoice the balance, and see whether you can get from the refund back to the appointment in one step.

I covered the rest of Square's free plan, including the API restriction, in the Square Appointments alternative piece. This article only cares about the money path.

Why we made the booking an order

The usual way to store a booking is as a calendar event with a payment attached to it. That holds up until someone wants half their money back on a two-session package. A calendar event has no idea what a line item is, so "refund one of the two sessions" has nowhere to live, and the refund ends up as a note.

So we copied the model Shopify uses for physical goods. A booking creates an order. The appointments are its line items. Every payment, refund and fee is a transaction on that order, and every change (reschedule, cancellation, add-on) goes in its activity log. Orders are numbered from #1001, the same way a shop numbers them.

That one decision does most of the work in the right-hand column above:

The invoicing side has its own walkthrough with the settings you configure once (legal name, tax ID, prefix, payment terms). The short version is that an invoice is a frozen snapshot of the order at the moment you issue it, so editing the booking next week doesn't quietly change a document the customer already has.

The same order through the API

This matters more to developers and agencies than to a salon owner, so skip it if you'll only ever use the dashboard.

If you build your own booking front end on the Storefront API, checkout returns a Stripe payment intent client secret, you collect the card with Stripe Elements, and the confirm call creates the booking and the order together. Confirm is idempotent, so a retried request after a dropped connection doesn't charge twice or book twice. Every merchant connects their own Stripe account and the charge is made on that account, which means the money never passes through us.

The practical effect: a custom site built on the API and the merchant's dashboard are looking at the same orders. There's no sync job between "the website's payments" and "the business's bookings", because there's only one record.

Pricing one month of it

Take a business doing 300 online bookings a month at an average of $90, so $27,000 through cards. I'm using US domestic online rates; Stripe's rate differs by country, so check yours.

Two things stand out. Square Free is not the cheap option once most of your revenue is online, because the 0.4-point rate gap costs $108 a month at this volume, more than double Plus's subscription. And our own pay-per-booking plan is the most expensive row in the table. Elastic is built for slow months and small volumes; our pricing page says a fixed plan costs less past roughly 16 bookings a month, and at 300 it isn't close. If you're busy, don't pick Elastic.

The Opencals rows also cover every location and staff member at that price, where Square's software line multiplies by location. Card processing is billed by Stripe directly; Opencals adds no fee on Stripe payments.

What's still in beta, and what we don't do

I'd rather you read this here than find it in week two.

Deposits and no-show fees are in beta. Our own deposits and cancellations page says they're not yet available to every store, and you contact us for early access. Cancellation windows with automatic refunds to the original card, and customer self-service cancellation inside the window, are available now. If deposits are the reason you're switching, ask before you migrate.

No card readers. Opencals takes payments online through Stripe or Shopify Payments, plus manual cash and bank-transfer records. There is no terminal and no in-person card rate. A business that takes most of its money at a counter should stay with Square; I said the same in the Square piece and it's still true.

We're not the payment company. Disputes and chargebacks are handled by Stripe or Shopify Payments, and if one goes against you there is nothing we can do from our side. The deposit fee article has more on what evidence helps.

The free store can't take real money. The free development store runs in test mode with every feature, so you can rehearse the whole fortnight above with test cards. You switch to production to take a real payment.

When you shouldn't buy booking and payments together

If you hold one-to-one calls and never charge for them, you want a meeting scheduler. Calendly is better at that than we are.

If you bill clients monthly for a retainer and bookings are just meetings inside it, an invoicing tool plus a scheduler is the right shape. The booking isn't the thing being sold, so tying payments to it adds nothing.

If you take money at a counter, see above: stay where your card reader is.

For everyone else, the business that sells appointments, sessions, rentals or classes and takes money online before, during or after, my recommendation is the test I described at the top. Run one booking through deposit, add-on, balance, partial refund. Count how many places you had to look. If it's more than one, you've found the cost the pricing page didn't show you. You can run that test on Opencals in a free development store, and on Square in a trial, before you commit to either.

If you're working out the money side in more detail, these go deeper on each piece: