Buchungssystem für TYPO3: Terminreservierung & Online-Buchung

Terminbuchung direkt auf der Website scheitert in TYPO3 oft an fehlender Extension-Reife

Unternehmen mit Beratungsterminen, Raumvermietung oder Kursangeboten wollen Online-Buchung direkt in ihre TYPO3-Website integrieren. Die Erwartung: Kalender, Verfügbarkeitsprüfung, Bezahlung, Bestätigungs-E-Mail, alles aus einem Guss. Die Realität: Es gibt im TYPO3-Extension-Repository (TER) keine einzelne Buchungs-Extension, die all diese Anforderungen produktionsreif abdeckt. Die vorhandenen Lösungen (jcc_appointment, cab_single_booking, diverse Eigenentwicklungen) bedienen Nischenfälle oder sind nicht aktiv gepflegt.

Deshalb ist ein TYPO3-Buchungssystem fast immer ein Hybrid: eine Basis-Extension oder Custom-Entwicklung für die Kernlogik, kombiniert mit Payment-Providern (Stripe, PayPal, Mollie) und Kalender-Schnittstellen (iCal, Google Calendar API). Gosign hat diesen Ansatz in über 15 Projekten umgesetzt.

Typische Einsatzszenarien

Beratungsunternehmen mit Terminvergabe. Steuerberater, Rechtsanwälte, Unternehmensberater brauchen ein System, bei dem Kunden freie Slots sehen und buchen können. Der Kalender synchronisiert sich mit dem Outlook oder Google Calendar des Beraters. Bezahlung ist optional (oft wird erst nach der Beratung abgerechnet), aber Storno-Fristen und No-Show-Gebühren müssen abbildbar sein. Ein typisches Setup: 3 Berater, 4 Leistungsarten, 30-Minuten-Slots, 2 Standorte.

Seminar- und Kursanbieter. Bildungsträger, Volkshochschulen, Sportvereine bieten Kurse mit begrenzten Plätzen an. Das Buchungssystem braucht Teilnehmerlisten, Wartelisten, Gruppen-Preise, Frühbucher-Rabatte und Serien-Termine (z.B. 10 Yoga-Stunden als Block). Payment erfolgt bei Buchung, Storno mit Teilrückerstattung muss automatisiert sein.

Raumvermietung und Ressourcen-Management. Coworking Spaces, Tagungshotels, Sportanlagen vermieten Räume oder Plätze stundenweise. Hier zählt die Verfügbarkeitsanzeige in Echtzeit: Kein Raum darf doppelt gebucht werden, auch wenn zwei Nutzer gleichzeitig auf “Buchen” klicken. Race-Condition-Protection auf Datenbankebene ist kein Nice-to-have, sondern Pflicht.

Technische Architektur

Ein produktionsreifes Buchungssystem in TYPO3 besteht aus vier Schichten. Die Datenbank-Schicht verwaltet Ressourcen (Räume, Personen, Geräte), Verfügbarkeiten (Zeitfenster, Sperrzeiten, Feiertage) und Buchungen (mit Status: angefragt, bestätigt, storniert, abgeschlossen). Die Logik-Schicht prüft Verfügbarkeit, verhindert Doppelbuchungen und berechnet Preise. Die Payment-Schicht kommuniziert mit externen Zahlungsanbietern über deren APIs. Die Benachrichtigungs-Schicht versendet Bestätigungen, Erinnerungen und Storno-Mails.

Für die Doppelbuchungs-Verhinderung gibt es drei Ansätze: pessimistisches Locking (SELECT … FOR UPDATE), optimistisches Locking (Versionsnummer in der Buchungstabelle) oder Queue-basiert (Buchungsanfragen werden sequenziell abgearbeitet). Die Wahl hängt von der erwarteten Last ab. Bei unter 100 Buchungen pro Tag reicht optimistisches Locking, bei Events mit 1.000 gleichzeitigen Zugriffen ist eine Queue robuster.

iCal-Export ist Standard: Jede bestätigte Buchung generiert eine .ics-Datei, die als Anhang in der Bestätigungs-E-Mail mitgesendet wird. Für bidirektionalen Sync (Buchung im TYPO3 erscheint im Google Calendar und umgekehrt) ist die Google Calendar API oder CalDAV nötig.

Häufige Probleme und Lösungen

Doppelbuchungen trotz Verfügbarkeitsprüfung. Die häufigste Ursache: die Prüfung “Ist der Slot frei?” und das Einfügen der Buchung laufen nicht in derselben Datenbank-Transaktion. Zwischen Prüfung und Insert können Millisekunden vergehen, in denen ein zweiter Nutzer denselben Slot bucht. Lösung: Prüfung und Insert in eine Transaktion mit Zeilensperre verpacken.

Payment-Callbacks kommen nicht an. Stripe und PayPal senden Zahlungsbestätigungen per Webhook. Wenn die TYPO3-Seite hinter einem Reverse Proxy oder einer Firewall liegt, erreichen die Callbacks den Server nicht. Lösung: Webhook-URL über eine dedizierte Route (z.B. /api/payment/webhook) bereitstellen, die nicht durch TYPO3-Caching oder .htaccess-Regeln blockiert wird. Testtools: Stripe CLI (stripe listen --forward-to), PayPal Sandbox Webhooks.

Zeitzonen-Chaos bei internationalen Buchungen. Wenn Buchende und Ressource in verschiedenen Zeitzonen sitzen, entstehen Fehler. Lösung: Alle Zeiten intern als UTC speichern, Anzeige im Frontend per JavaScript an die lokale Zeitzone des Nutzers anpassen.

Migration und Versions-Kompatibilität

Es gibt keine einheitliche Buchungs-Extension mit offiziellem TYPO3 v12/v13-Support. Die meisten verfügbaren Extensions sind auf v10 oder v11 stehengeblieben. Wer ein bestehendes Buchungssystem auf TYPO3 v12+ migriert, hat zwei Optionen: Die Custom-Logik auf Extbase/Doctrine portieren (v12-kompatibel) oder die Buchungslogik als API-Microservice auslagern und nur das Frontend in TYPO3 rendern.

Für Neuentwicklungen empfiehlt sich ein API-first-Ansatz: Die Buchungs-Engine als REST-API (in TYPO3 oder als separater Service), das Frontend als Web-Komponente, die in jedes TYPO3-Template eingebettet werden kann. Damit bleibt das Buchungssystem unabhängig von TYPO3-Major-Upgrades. Gosign setzt diesen Ansatz seit 2024 als Standard um.

Wer ein externes Buchungssystem (Calendly, SimplyBook.me, Timify) nutzt und nur die Oberfläche in TYPO3 einbetten will, hat eine dritte Option: Das externe System per iframe oder JavaScript-Widget einbinden. Das funktioniert schnell, hat aber Nachteile: kein einheitliches Design, Datenschutz-Fragen (Drittanbieter-Cookies, Datenübertragung in die USA) und keine Kontrolle über den Buchungsablauf. Für DSGVO-sensible Branchen (Gesundheitswesen, Rechtsberatung, öffentliche Verwaltung) ist die Custom-Entwicklung innerhalb von TYPO3 oder als eigener Microservice die sauberere Lösung.

Gosign kalkuliert ein typisches Buchungssystem-Projekt (3 Ressourcentypen, Stripe-Payment, E-Mail-Workflows, iCal-Export) mit 15 bis 25 Entwicklungstagen. Davon entfallen etwa 40 % auf die Buchungslogik mit Verfügbarkeitsprüfung, 25 % auf die Payment-Integration, 20 % auf E-Mail-Templates und Benachrichtigungen und 15 % auf Frontend-Darstellung und Testing.

Für die Wartung nach Go-Live sind zwei Aspekte kritisch. Erstens: Payment-APIs ändern sich. Stripe und PayPal aktualisieren ihre APIs regelmässig, alte Versionen werden nach 12 bis 24 Monaten abgeschaltet. Ein Buchungssystem, das nicht gewartet wird, akzeptiert irgendwann keine Zahlungen mehr. Zweitens: Kalender-Sync muss überwacht werden. OAuth-Tokens für Google Calendar laufen nach 7 Tagen ab, wenn kein Refresh-Mechanismus implementiert ist. Gosign richtet Monitoring für beide Szenarien ein, damit Ausfälle innerhalb von Minuten erkannt und behoben werden.