A calendar is not a booking system. The real product is the rule around the slot: which service fits, how much time it blocks, who may take it, whether travel time is needed, when a deposit is charged and what happens when somebody cancels.
Describe those rules before describing the colours. Vantix turns them into a flow the customer can understand, with the pages around it, the confirmation after it and ordinary code a developer can inspect when the rules become more complex.
The customer should know what they are booking, how long it takes, what it costs, where it happens and when it is confirmed. Showing those answers before the final button prevents support messages and cancellations later.
For classes or rentals, capacity and date ranges replace staff calendars but the principle is the same: expose only choices that can really be honoured.
A clinic with regulated patient data, a hotel with channel management, or a marketplace coordinating hundreds of providers should use specialised software. Those products exist because scheduling, compliance and reconciliation become operations in their own right.
Vantix fits the custom middle: the standard widget is too rigid, but the business is still small enough that its rules can be explained, built and tested as one application.
Yes, through Stripe. Keep raw card data in Stripe’s hosted flow and test failed or abandoned payments.
Only if you connect and implement the calendar provider you use. Calendar access is not one of the eleven ready connectors today, so do not assume it exists.
Yes. Define the cutoff, refund rule and confirmation behaviour explicitly so cancellation is part of the flow rather than a support email.
Not without a separate compliance review and the right data-processing setup. A normal booking form should not collect medical details.
Build the flow customers can actually finish.