A free online booking system can provide appointment scheduling and payment integrations without a subscription to that particular plan, but that does not make payment processing free or establish that a Zambia-based business can use its gateways. Compare the booking plan, merchant eligibility and payment workflow separately before choosing a system.
Setmore advertises a Free plan with online booking and integrations including Square, Stripe and PayPal, while noting that providers may charge transaction fees. That is a useful starting candidate, not confirmation that those payment routes accept your business. A WordPress alternative using WooCommerce Bookings and Deposits has different setup responsibilities and should not be described as a free equivalent. Setmore booking and payments, WooCommerce deposits integration.
Which booking approach fits your service?
Begin with the appointment rather than the software brand. Specify whether a customer chooses a staff member, a room, a class or an individual consultation. Record whether availability is confirmed immediately or requires approval, and whether payment is taken before that approval.
A small service business may value a hosted booking page that keeps scheduling separate from its website. A business with an existing WooCommerce catalogue may instead need bookable products within that store. These are selection considerations, not claims that either approach is universally easier or less expensive.
Also decide whether customers must pay a deposit, the whole balance or nothing at the request stage. Do not let a system’s default wording decide your cancellation terms. The business needs a clearly described process for declining a request, changing an appointment and returning money when appropriate. The software demonstration should follow that process.
How do a hosted booking page and WooCommerce compare?
| Question | Hosted Setmore route | WordPress booking route |
|---|---|---|
| What is the documented entry option? | Setmore advertises a Free plan with payment integrations | WooCommerce documents Bookings plus a separately sold Deposits extension |
| Where do you evaluate payment access? | Against the selected connected provider and merchant account | Against the store’s gateway and merchant account |
| How are deposits represented? | Setmore describes service deposits | Deposits settings can be applied to bookable products |
| What must be demonstrated? | Booking page, chosen payment route and balance handling | Booking status, linked order and deposit schedule |
| What remains unproved here? | Zambia eligibility and actual account access | Zambia eligibility and the site’s tested configuration |
This comparison is deliberately about documented workflow differences. It does not convert a United States-facing Setmore page into evidence of Zambian merchant availability, nor assume that a WordPress plugin removes payment-provider restrictions.
Does a confirmed booking mean the customer has paid?
Not necessarily. WooCommerce’s booking manager documentation distinguishes booking status from linked order status and attendance. A confirmed booking does not always have an order or payment due. The Complete status is likewise not proof of attendance or payment. These distinctions prevent staff from relying on a single calendar colour for financial decisions.
The same documentation explains that bookings requiring confirmation request approval without collecting payment at that stage. Where an associated order remains pending payment, the confirmation email can contain a payment link. Check the exact relationship in the selected configuration rather than assuming “confirmed” means money was collected.
Most importantly, manually marking a booking Paid does not charge the customer. Record that as an operating rule in staff instructions. A payment decision should point to payment evidence, not merely to a booking label. Official booking status guide.
What should a deposit workflow show the customer?
Write a plain description of what the initial payment secures and how the remaining balance is handled. The customer should be able to understand the appointment requested, its approval state and any outstanding payment without reading internal accounting labels.
WooCommerce’s Deposits integration allows storewide plans and product-specific settings. That flexibility means two bookable products can behave differently if configured differently. During testing, inspect the individual product rather than checking only the storewide setting. Show the resulting booking and payment information on the customer account page as part of the acceptance exercise.
Do not invent a cancellation percentage, payment deadline or forfeiture term because a settings field requires a value. Those are business decisions to document before configuration. A tutorial can explain where the decisions belong without writing commercial terms on the business’s behalf.
A booking and payment acceptance card
Use this original card for each service type. It turns a software comparison into a demonstration that can be evaluated consistently.
Service and resource: what is booked, who supplies it and which calendar controls availability.
Request state: whether submission is a request or an immediate confirmed booking.
Payment state: deposit due, deposit received, balance outstanding or full payment received, supported by the relevant order record.
Customer evidence: booking reference, appointment details, confirmation wording and next action.
Cancellation case: customer requests cancellation; operator records the booking outcome and separately checks the money movement.
Exception case: payment is incomplete or the confirmation email does not arrive; staff can locate the request without taking payment again unnecessarily.
Acceptance result: actual observed behaviour, outstanding discrepancy and owner of the next action.
Use test customers and the provider’s authorised testing environment. Prevent rehearsals from sending genuine reminders or creating unintended charges. The card is an editorial aid, not a claim that either system has passed these cases for Spout.
Why must cancellations and refunds be tested separately?
WooCommerce explicitly says cancelling a booking does not automatically refund its payment. An operator must handle a refund through the linked order. A cancelled appointment and returned funds are therefore separate evidence points.
Test the customer view after cancellation, the staff calendar and the linked payment record. If the booking is cancelled but the refund is pending, say that clearly. Do not send a message implying the funds have returned merely because the appointment disappeared from the calendar.
Choose the system whose documented features and actual demonstration fit your service process. Keep unanswered gateway eligibility and plan questions visible before enabling paid bookings.
Discuss your booking workflow through Spout’s web development service or start an enquiry. Bring the completed acceptance card rather than only a preferred product name.
By Spout Team. Prepared with AI-assisted drafting using the linked primary documentation.