Ticketshop para TYPO3

Los organizadores pagan entre un 5 y un 15 por ciento de comisión a plataformas de ticketing externas cuando su propio sitio sería el mejor canal de venta

Plataformas como Ticketmaster, Entradas.com o Eventbrite cobran comisiones por ticket: entre un 5 y un 15 por ciento del precio más un importe fijo. Para un teatro con 50.000 entradas vendidas al año y un precio medio de 30 euros, eso supone entre 75.000 y 225.000 euros de comisión anual. Un ticketshop directamente en el sitio web TYPO3 elimina esa comisión. La extensión permite la venta de entradas en línea con selección de asiento, gestión de cupos, pago a través de pasarelas habituales, generación de e-tickets en PDF y validación por código QR en la entrada. Para teatros, auditorios, conferencias y centros culturales municipales que venden la mayor parte de sus entradas a un público habitual conocido, es una alternativa económicamente atractiva.

Los escenarios típicos van desde el teatro municipal hasta la conferencia profesional

El escenario más prominente es el teatro o auditorio con plano de sala fijo. 400 asientos numerados, de los cuales 50 en categoría Premium, 200 en platea y 150 en anfiteatro. El visitante elige su asiento en el plano interactivo, ve el precio y añade la entrada al carrito. Tras el pago, recibe un e-ticket en PDF con código QR por correo electrónico. La noche de la función, el personal escanea el código QR con un smartphone. Todo el proceso se desarrolla en el sitio TYPO3, sin terceros.

Un segundo escenario son las conferencias y ferias. Una conferencia profesional ofrece tres categorías de entradas: Early Bird (hasta 8 semanas antes del evento), Regular y VIP. Los cupos limitan cada categoría a un número fijo. El ticketshop muestra la disponibilidad en tiempo real: “Early Bird: 12 de 100 disponibles”. Al finalizar el periodo Early Bird, la categoría se desactiva automáticamente.

Tercer escenario: eventos municipales. Una biblioteca municipal organiza lecturas, talleres y actividades infantiles. Las entradas son gratuitas, pero el aforo es limitado. El ticketshop funciona aquí como sistema de reservas. Los visitantes reservan en línea, reciben una confirmación y, en caso de exceso de demanda, se incorporan a una lista de espera.

La arquitectura técnica conecta registros de eventos, plano de sala y pasarela de pago

El ticketshop se compone de cuatro componentes: gestión de eventos, editor de plano de sala, checkout con integración de pago y generación de tickets. Los eventos se crean como registros Extbase en el backend de TYPO3: título, fecha, hora, lugar, categorías, precios, cupos. El plano de sala se registra como gráfico SVG interactivo en el que cada asiento tiene un identificador único vinculado al sistema de cupos.

El proceso de checkout recoge las entradas seleccionadas, solicita los datos de contacto y redirige a una pasarela de pago. Integraciones habituales son Stripe, PayPal, Mollie y Redsys. Tras un pago correcto, la extensión genera un PDF de entrada con código QR (basado en un identificador único de ticket) y lo envía por correo electrónico. El código QR contiene una URL o un hash que se valida en el control de acceso.

La validación del código QR en la entrada puede funcionar con una aplicación web sencilla que comprueba el identificador del ticket contra la base de datos TYPO3 y marca el estado como “canjeado”. Un ticket solo se puede canjear una vez; los duplicados se rechazan.

Los problemas habituales afectan al pago, las cancelaciones y el editor del plano de sala

El mayor problema es la gestión del pago. El cumplimiento de PCI-DSS exige que los datos de tarjeta nunca lleguen al servidor propio. Por eso el pago debe procesarse a través de un proveedor certificado que proporcione un Hosted Payment Form. La extensión redirige al usuario al proveedor para el pago y recibe el resultado mediante callback. Si el callback falla (timeout, reinicio del servidor), el ticket está pagado pero no marcado como pagado. La solución: un job de reconciliación que verifique las transacciones pendientes contra el proveedor de pago.

Segundo problema: cancelaciones y reembolsos. Si un visitante cancela una entrada, el pago debe reembolsarse y la plaza liberarse. Esto requiere tanto una petición de reembolso al proveedor de pago como un cambio de estado en la base de datos TYPO3. Sin flujo automatizado de cancelación, es un proceso manual.

Tercer tema: el editor del plano de sala. Los planos SVG interactivos con 400 asientos o más son laboriosos de crear. Cada asiento necesita un identificador, una categoría y coordenadas. Los cambios en el plano (nuevo bloque, reordenación) obligan a actualizar el archivo SVG y los vínculos con la base de datos.

Los ticketshops son desarrollos a medida sin estándar en el TER

No existe una extensión de ticketshop estándar en el TYPO3 TER que cubra todas las funciones descritas. Los ticketshops son casi siempre desarrollos a medida adaptados a las necesidades específicas del recinto. La compatibilidad con TYPO3 depende por tanto del proveedor, no de un ciclo de lanzamientos comunitario. Gosign recomienda en los nuevos proyectos de ticketshop evaluar si una arquitectura headless de TYPO3 con un frontend especializado (React, Vue) no es a largo plazo más mantenible que una solución monolítica Extbase.