Booking software for agencies: what changes at the fourth client
First, a sorting question, because Google sends two very different people to this page.
If your agency sells flights, hotels and tours, you want travel agency software: supplier inventory, GDS connections, commission tracking, itineraries. Opencals does none of that, and neither does anything else on this blog. The travel agency lists on Capterra are the right place to start, and I'd rather you leave now than read ten minutes to find out.
This page is for the other kind of agency: the studio that builds websites for a salon, a physio clinic, a padel club and a car rental firm, and gets asked by every one of them, "can people book and pay on the site?"
For a web or dev agency, booking software is chosen per portfolio, not per client. Four questions decide it: whose payment account takes the money, how the software bill behaves in a client's slow month, whether your own code can write bookings on the plan the client actually pays for, and what the client keeps when you stop maintaining the site. Opencals answers them with one engine and a separate store per client: each client connects their own Stripe account, the REST API and TypeScript SDK work on every plan including the free development store, and pricing is per booking or from $14.98 a month. It is not open source (only the templates and SDK are), and deposits are still in beta.
The fourth client is where the widget plan stops working
The first booking site is easy. You sign the client up for whatever scheduler they've heard of, paste its widget into the page, adjust the colours as far as the vendor allows, and move on.
By the fourth client you have four vendor accounts with four sets of logins, four widgets that each look slightly wrong against your design, and four support routes. When the salon's widget breaks on mobile, you can't fix it, because the code isn't yours. When the physio asks for an intake question before checkout, the answer depends on which plan they're on. And when the padel club wants court hire priced by the hour with racket rental as an extra, the widget they're on doesn't model it at all.
None of that is a criticism of any single tool. It's what happens when booking is chosen per client and your agency is the thing holding it together. The questions below are the ones I'd settle once, for the whole portfolio.
Whose Stripe account takes the money?
This one has legal and practical weight, so I'd decide it first.
If the payments land in an account you control and you pay the client out, you're holding client money. That brings refund handling, disputes and reconciliation onto your desk, and in some places it brings regulation too. The cleaner arrangement is that every client has their own payment account, the charge is made on it, and you never touch the funds.
In Opencals each merchant connects their own Stripe account, and the charge is made directly on it. We add no fee on Stripe payments, so Stripe's own rate is the whole processing cost (2.9% + 30¢ on domestic online cards in the US; it differs by country). A dispute goes between the client and Stripe. Your agency is in the build, not the money flow.
Shopify-based clients can take payment through Shopify Payments instead, and anyone who wants a record of cash or bank transfers can mark those on the order by hand.
Who pays the booking bill in February?
The second question is commercial. If you resell a subscription, you own the conversation every time a client asks why they're paying $49 in a month they had six bookings.
Here's how the two Opencals plans behave for clients of different sizes, with prices from our pricing page as of October 2026:
| Client, bookings a month | Elastic ($0.99 per booking) | Fixed plan (from $14.98, 300 included) |
|---|---|---|
| Seasonal tour guide in February, 3 | $2.97 | $14.98 |
| Solo physio, 10 | $9.90 | $14.98 |
| Barbershop, 40 | $39.60 | $14.98 |
| Salon with four stylists, 120 | $118.80 | $14.98 |
| Padel club, 250 | $247.50 | $14.98 |
The crossover is around 16 bookings a month, and that's the honest headline: Elastic is for the quiet clients and the ones still finding customers. Anyone busier belongs on the fixed plan, and if you put a busy client on Elastic you'll be explaining a three-figure bill. The fixed plan has add-ons on top: customer self-service is $14.99, white label is $4.99, so a busy salon with both lands around $35 a month. That covers every staff member and every location the client has.
Card processing is billed by Stripe on top in both columns.
Can your code write a booking on the plan the client pays for?
This is the question agencies forget to ask until the integration is half built.
When I was researching the Square Appointments comparison, Square's Bookings API documentation said that seller-level write calls need Appointments Plus or Premium, and fail with a 403 on the free plan. Square's pricing page puts Plus at $49 per location per month. So a custom booking front end for twelve shop clients on Square needs each of them on a paid plan before your integration can create a booking, which is $7,056 a year across the portfolio before anyone has paid for a haircut.
That isn't unusual. Plenty of booking tools keep the API on a higher tier, because the API is how people leave the vendor's booking page. Check the plan line, not the docs homepage.
On Opencals the REST API, the TypeScript SDK and webhooks are on every plan, including the free development store, so you can build the whole flow against test data before the client pays anything. Each client is a separate store with its own key, which means one codebase can serve all of them:
import { setupOpencals } from "@opencals/storefront-sdk";
// One deployment per client; only the key changes.
setupOpencals({
apiKey: process.env.OPENCALS_API_KEY, // sfk_... for this client's store
});From there, availability, cart, Stripe checkout and customer rescheduling are the same calls for every client. The developers page has the endpoints, and the booking SDK walkthrough shows the five calls a typical flow makes.
What does the client keep when the retainer ends?
Agencies don't like to think about this one, and clients do, usually at the worst moment.
If you hand-built the booking backend, the honest answer is "a codebase someone else now has to understand". If the booking lives in a vendor widget under your account, it's "whatever we can migrate". Both put pressure on a relationship that's already ending.
My recommendation, whatever you choose: set it up so the client owns the store and the payment account, and your agency has a role on it. Then the end of a retainer changes who updates the website, and nothing else. The client keeps their dashboard, their customers, their order history and their Stripe balance, and they can point a different front end at the same store later.
How the pieces fit for an agency
What you'd actually use, in order:
Start from a template
The Next.js booking templates are MIT-licensed: Haar for salons, Frisor for barbers, Clarity for clinics, Volt for padel and squash clubs, plus car rental and language-school templates. Point one at a store ID and you have a working booking site to restyle.
Build against a free development store
Every feature and API endpoint runs in test mode, seeded with sample business data, with no card and no trial clock. Use it to demo the flow to the client before they sign anything.
Move the client to production
The client connects their own Stripe account and picks Elastic or a fixed plan based on volume. White label is a $4.99 add-on if they don't want Opencals branding.
Run the portfolio from one place
The agency workspace lets you switch between client stores from one login. Partner terms and the agency setup are on the agencies page.
The agencies page has the partner terms. The templates and their source are on the open-source page.
Where I'd send you somewhere else
If your clients mostly book one-to-one calls and don't take money, Calendly or Cal.com will do the job with less setup, and I'd use them.
If a client takes most of their money at a counter, Square's reader is a reason to stay on Square. Opencals takes payments online only and doesn't ship hardware.
If a client's requirement is that everything runs on their own servers, we're the wrong answer: the templates and SDK are MIT, but the booking engine is a hosted service and will stay that way. The open-source booking roundup covers the self-hosted route.
And two limits of ours you should know before you quote a client. Deposits and no-show fees are in beta and not yet on every store; ask us before you promise them. And the free development store is test mode only, so a client can't take a real payment until they move to a paid plan.
If none of those apply and you're building booking for more than three service businesses, I'd pick one engine for the whole portfolio, decide the four questions once, and stop choosing per client. Spin up a development store and build your next client's flow against it before you commit to anything.
If you're planning the build itself, these cover the technical side:
Booking systems for developers
What you still build yourself: availability, reschedule links, payments and reminders.
Booking SDK walkthrough
The five calls a typical booking flow makes, with the typed TypeScript SDK.
Headless booking system
Run booking behind your own UI, and when that's worth the extra work.
Booking and payments software
Deposit, add-on, invoice and refund on one order, priced against Square.
Build a booking website with AI
Lovable, v0 and Base44 wired to a real booking and payments backend.
Square Appointments alternative
Why seller-level API writes need a paid Square plan, per location.
Frequently Asked Questions
Get started
Ready to transform your service business?
Join 150+ businesses already using Opencals. Start on a free development store with every feature unlocked, and only pay once you go live.