Ticket Shop for TYPO3

Organizers pay ticketing platforms 5 to 15 percent commission, although their own website would be the better sales channel

Eventim, Ticketmaster and Eventbrite charge fees on every ticket: between 5 and 15 percent of the ticket price plus a fixed amount. For a theater selling 50,000 tickets a year at an average price of €30, that adds up to €75,000 to €225,000 in commission annually. A ticket shop running directly on the TYPO3 website eliminates this commission. The extension handles online ticket sales with seat selection, quota management, payment through the usual payment providers, e-tickets generated as PDFs and QR code validation at the entrance. For theaters, concert halls, conferences and municipal venues that sell most of their tickets to a known, loyal audience, this is an economically attractive alternative.

Use cases range from the city theater to the specialist conference

The most prominent scenario is a theater or concert hall with a fixed seating plan: 400 numbered seats, 50 of them in the premium category, 200 in the stalls and 150 in the balcony. The visitor picks a seat on the interactive seating plan, sees the price and adds the ticket to the cart. After payment, an e-ticket arrives by email as a PDF with a QR code. On the evening of the performance, staff scan the QR code with a smartphone. The whole process runs on the TYPO3 website, without any third-party provider.

A second scenario is conferences and trade fairs. A specialist conference offers three ticket categories: Early Bird (up to 8 weeks before the event), Regular and VIP. Quotas cap each category at a fixed number. The ticket shop shows availability in real time: “Early Bird: 12 of 100 available”. When the early bird period ends, the category is deactivated automatically.

Third scenario: municipal events. A public library hosts readings, workshops and events for children. Tickets are free, but places are limited. Here the ticket shop works as a reservation system. Visitors reserve online, receive a confirmation and are put on a waiting list if the event is overbooked.

The architecture connects event records, seating plan and payment gateway

The ticket shop consists of four components: event management, a seating plan editor, a checkout with payment integration and ticket generation. Events are created as Extbase records in the TYPO3 backend: title, date, time, venue, categories, prices, quotas. The seating plan is stored as an interactive SVG graphic in which every seat has a unique ID linked to the quota system.

The checkout collects the selected tickets, asks for contact details and redirects to a payment gateway. Common integrations are Stripe, PayPal, Mollie and Worldline (formerly SIX Payment Services). After successful payment, the extension generates a PDF ticket with a QR code (based on a unique ticket ID) and sends it by email. The QR code contains a URL or a hash value that is validated at the entrance.

QR code validation at the door can run through a simple web app that checks the ticket ID against the TYPO3 database and sets its status to “redeemed”. Each ticket can be redeemed only once; duplicates are rejected.

The typical pain points are payment, cancellations and the seating plan editor

The biggest problem is payment processing. PCI DSS sets the rules here: as soon as card data touches your own server, the full set of compliance requirements applies. That is why payment has to run through a certified payment provider that offers a hosted payment form. The extension redirects the user to the provider for payment and receives the result via callback. If the callback fails (timeout, server restart), the ticket has been paid for but is not marked as paid. The fix: a reconciliation job that rechecks open transactions with the payment provider.

Second problem: cancellations and refunds. When a visitor cancels a ticket, the payment has to be refunded and the seat released again. That requires both a refund request to the payment provider and a status change in the TYPO3 database. Without an automated cancellation workflow, this remains a manual process.

Third issue: the seating plan editor. Interactive SVG seating plans with 400 or more seats take considerable effort to create. Every seat needs an ID, a category and coordinates. Changes to the seating plan (a new block, a different seat order) require updating both the SVG file and the links in the database.

Ticket shop extensions are custom builds without a TER standard

There is no standard ticket shop extension in the TYPO3 Extension Repository (TER) that covers all the functions described here. Ticket shops are almost always custom developments tailored to the specific requirements of the venue. TYPO3 compatibility therefore depends on the contractor, not on a community release cycle. For new ticket shop projects, Gosign recommends assessing whether a headless TYPO3 architecture with a dedicated frontend (React, Vue) will be easier to maintain in the long run than a monolithic Extbase solution.