Booking System for TYPO3: Appointment Reservation & Online Booking

Appointment booking on the website fails in TYPO3 because no single extension is production-ready

Organizations with consulting appointments, room rentals or course offerings want to integrate online booking directly into their TYPO3 website. The expectation: calendar, availability check, payment, confirmation email - all from a single source. The reality: there is no single booking extension in the TYPO3 Extension Repository (TER) that covers all these requirements in a production-ready way. The available solutions (jcc_appointment, cab_single_booking, various custom developments) serve niche cases or are no longer actively maintained.

That is why a TYPO3 booking system is almost always a hybrid: a base extension or custom development for the core logic, combined with payment providers (Stripe, PayPal, Mollie) and calendar interfaces (iCal, Google Calendar API). Gosign has implemented this approach in over 15 projects.

Typical use cases

Consulting firms with appointment scheduling. Tax advisors, law firms, management consultants need a system where clients can see and book available slots. The calendar syncs with the consultant’s Outlook or Google Calendar. Payment is optional (billing often happens after the session), but cancellation deadlines and no-show fees must be configurable. A typical setup: 3 consultants, 4 service types, 30-minute slots, 2 locations.

Seminar and course providers. Education providers, community colleges and sports clubs offer courses with limited seats. The booking system needs participant lists, waiting lists, group pricing, early-bird discounts and recurring dates (e.g. 10 yoga sessions as a block). Payment at booking time, cancellation with partial refund must be automated.

Room rental and resource management. Coworking spaces, conference hotels and sports facilities rent rooms or spaces by the hour. Real-time availability display is critical: no room may be double-booked, even when two users click “Book” simultaneously. Race condition protection at database level is not a nice-to-have - it is mandatory.

Technical architecture

A production-ready booking system in TYPO3 consists of four layers. The database layer manages resources (rooms, people, equipment), availabilities (time slots, blocked periods, holidays) and bookings (with status: requested, confirmed, canceled, completed). The logic layer checks availability, prevents double bookings and calculates prices. The payment layer communicates with external payment providers through their APIs. The notification layer sends confirmations, reminders and cancellation emails.

For double-booking prevention, there are three approaches: pessimistic locking (SELECT … FOR UPDATE), optimistic locking (version number in the booking table) or queue-based (booking requests processed sequentially). The choice depends on expected load. Under 100 bookings per day, optimistic locking suffices; for events with 1,000 concurrent accesses, a queue is more robust.

iCal export is standard: every confirmed booking generates an .ics file sent as an attachment in the confirmation email. For bidirectional sync (booking in TYPO3 appears in Google Calendar and vice versa), the Google Calendar API or CalDAV is required.

Common problems and solutions

Double bookings despite availability checking. The most common cause: the check “Is the slot free?” and the insert of the booking do not run in the same database transaction. Between check and insert, milliseconds can pass during which a second user books the same slot. Solution: wrap check and insert in a single transaction with row locking.

Payment callbacks not arriving. Stripe and PayPal send payment confirmations via webhook. If the TYPO3 site sits behind a reverse proxy or firewall, the callbacks cannot reach the server. Solution: provide a dedicated route (e.g. /api/payment/webhook) for the webhook that is not blocked by TYPO3 caching or .htaccess rules. Testing tools: Stripe CLI (stripe listen --forward-to), PayPal Sandbox Webhooks.

Timezone chaos with international bookings. When the booker and the resource are in different timezones, errors arise. Solution: store all times internally as UTC, adjust display in the frontend via JavaScript to the user’s local timezone.

Migration and version compatibility

There is no unified booking extension with official TYPO3 v12/v13 support. Most available extensions have stalled at v10 or v11. Those migrating an existing booking system to TYPO3 v12+ have two options: port the custom logic to Extbase/Doctrine (v12-compatible) or extract the booking logic as an API microservice and only render the frontend in TYPO3.

For new developments, an API-first approach is recommended: the booking engine as a REST API (within TYPO3 or as a separate service), the frontend as a web component that can be embedded in any TYPO3 template. This keeps the booking system independent of TYPO3 major upgrades. Gosign has implemented this approach as standard since 2024.

Organizations using an external booking system (Calendly, SimplyBook.me, Timify) and wanting only to embed the interface in TYPO3 have a third option: integrate the external system via iframe or JavaScript widget. This works quickly but has drawbacks: no unified design, privacy concerns (third-party cookies, data transfer to the US) and no control over the booking flow. For GDPR (UK: UK GDPR)-sensitive industries (healthcare, legal advice, public administration), custom development within TYPO3 or as a dedicated microservice is the cleaner solution.

Gosign estimates a typical booking system project (3 resource types, Stripe payment, email workflows, iCal export) at 15 to 25 development days. Of that, approximately 40% goes to booking logic with availability checking, 25% to payment integration, 20% to email templates and notifications, and 15% to frontend display and testing.

Two aspects are critical for post-launch maintenance. First: payment APIs change. Stripe and PayPal update their APIs regularly, and old versions are retired after 12 to 24 months. A booking system that is not maintained will eventually stop accepting payments. Second: calendar sync must be monitored. OAuth tokens for Google Calendar expire after 7 days if no refresh mechanism is implemented. Gosign sets up monitoring for both scenarios so that outages are detected and resolved within minutes.