Buchungssystem para TYPO3: Terminreservierung & Online-Buchung

La reserva de citas directa en la web falla en TYPO3 a menudo por la inmadurez de las extensiones

Empresas con citas de asesoría, alquiler de espacios u ofertas de cursos quieren integrar la reserva online directamente en su web TYPO3. La expectativa: calendario, verificación de disponibilidad, pago, correo de confirmación - todo integrado. La realidad: no existe en el TYPO3 Extension Repository (TER) una única extensión de reservas que cubra todos estos requisitos en calidad de producción. Las soluciones disponibles (jcc_appointment, cab_single_booking, diversos desarrollos propios) atienden nichos o no se mantienen activamente.

Por eso un sistema de reservas TYPO3 es casi siempre un híbrido: una extensión base o desarrollo a medida para la lógica central, combinado con proveedores de pago (Stripe, PayPal, Mollie) e interfaces de calendario (iCal, Google Calendar API). Gosign ha implementado este enfoque en más de 15 proyectos.

Escenarios de uso habituales

Consultorías con gestión de citas. Asesores fiscales, abogados, consultoras necesitan un sistema donde los clientes vean huecos libres y reserven. El calendario se sincroniza con el Outlook o Google Calendar del asesor. El pago es opcional (a menudo se factura después de la consulta), pero plazos de cancelación y penalizaciones por no-show deben ser configurables. Un setup típico: 3 asesores, 4 tipos de servicio, slots de 30 minutos, 2 sedes.

Centros de formación y cursos. Centros educativos, escuelas de idiomas o clubes deportivos ofrecen cursos con plazas limitadas. El sistema de reservas necesita listas de participantes, listas de espera, precios de grupo, descuentos por reserva anticipada y sesiones en serie (por ejemplo, 10 clases de yoga como bloque). El pago se realiza al reservar, la cancelación con reembolso parcial debe estar automatizada.

Alquiler de espacios y gestión de recursos. Espacios de coworking, hoteles de conferencias e instalaciones deportivas alquilan salas o pistas por horas. Aquí cuenta la visualización de disponibilidad en tiempo real: ningún espacio puede reservarse dos veces, aunque dos usuarios pulsen “Reservar” simultáneamente. La protección contra race conditions a nivel de base de datos no es un nice-to-have, sino una obligación.

Arquitectura técnica

Un sistema de reservas productivo en TYPO3 consta de cuatro capas. La capa de base de datos gestiona recursos (salas, personas, equipos), disponibilidades (ventanas horarias, bloqueos, festivos) y reservas (con estados: solicitada, confirmada, cancelada, completada). La capa lógica verifica disponibilidad, previene dobles reservas y calcula precios. La capa de pago se comunica con proveedores de pago externos vía sus APIs. La capa de notificaciones envía confirmaciones, recordatorios y correos de cancelación.

Para prevenir dobles reservas existen tres enfoques: bloqueo pesimista (SELECT … FOR UPDATE), bloqueo optimista (número de versión en la tabla de reservas) o basado en cola (las solicitudes se procesan secuencialmente). La elección depende de la carga esperada. Con menos de 100 reservas diarias basta el bloqueo optimista; en eventos con 1.000 accesos simultáneos, una cola es más robusta.

La exportación iCal es estándar: cada reserva confirmada genera un archivo .ics adjunto al correo de confirmación. Para sincronización bidireccional (la reserva en TYPO3 aparece en Google Calendar y viceversa) se necesita la Google Calendar API o CalDAV.

Problemas frecuentes y soluciones

Dobles reservas a pesar de verificación de disponibilidad. La causa más frecuente: la comprobación “está libre el slot” y la inserción de la reserva no se ejecutan en la misma transacción de base de datos. Entre comprobación e INSERT pueden pasar milisegundos en los que un segundo usuario reserva el mismo slot. Solución: encapsular verificación e INSERT en una transacción con bloqueo de fila.

Los callbacks de pago no llegan. Stripe y PayPal envían confirmaciones de pago vía webhook. Si la web TYPO3 está detrás de un reverse proxy o firewall, los callbacks no alcanzan el servidor. Solución: proporcionar la URL del webhook mediante una ruta dedicada (por ejemplo, /api/payment/webhook) que no esté bloqueada por el caché de TYPO3 ni por reglas .htaccess.

Caos de zonas horarias en reservas internacionales. Cuando reservante y recurso están en distintas zonas horarias, surgen errores. Solución: almacenar todos los horarios internamente como UTC, mostrar en el frontend ajustado a la zona horaria local del usuario mediante JavaScript.

Migración y compatibilidad de versiones

No existe una extensión unificada de reservas con soporte oficial para TYPO3 v12/v13. La mayoría de las extensiones disponibles se han quedado en v10 o v11. Quien migra un sistema de reservas existente a TYPO3 v12+ tiene dos opciones: portar la lógica personalizada a Extbase/Doctrine (compatible con v12) o externalizar la lógica de reservas como microservicio API y renderizar solo el frontend en TYPO3.

Para nuevos desarrollos se recomienda un enfoque API-first: el motor de reservas como API REST (dentro de TYPO3 o como servicio separado), el frontend como componente web embebible en cualquier plantilla TYPO3. Así el sistema de reservas permanece independiente de las actualizaciones major de TYPO3. Gosign aplica este enfoque como estándar desde 2024.

Quien utiliza un sistema de reservas externo (Calendly, SimplyBook.me, Timify) y solo quiere incrustar la interfaz en TYPO3 tiene una tercera opción: integrar el sistema externo vía iframe o widget JavaScript. Funciona rápido pero tiene inconvenientes: diseño no unificado, cuestiones de protección de datos (cookies de terceros, transferencia de datos fuera de la UE conforme al RGPD y las directrices de la AEPD) y sin control sobre el flujo de reserva. Para sectores sensibles al RGPD (sanidad, asesoría legal, administración pública) el desarrollo a medida dentro de TYPO3 o como microservicio propio es la solución más limpia.

Gosign estima un proyecto típico de sistema de reservas (3 tipos de recurso, pago con Stripe, flujos de correo, exportación iCal) en 15 a 25 días de desarrollo. De estos, aproximadamente el 40 % corresponde a la lógica de reservas con verificación de disponibilidad, el 25 % a la integración de pagos, el 20 % a plantillas de correo y notificaciones, y el 15 % a la presentación frontend y testing.