Event ticketing website development

The chain a ticketing site holds together

A ticket page is the visible part of something longer. Behind it sit an event with a real capacity, inventory that must never be sold twice, a buyer who becomes a named attendee, a payment you can trust, an entitlement issued against it, an admission recorded once at the door, and a route for the day a ticket changes hands or the event moves. Ticketing is also compressed in a way a shop is not. A shop can absorb a bad hour, while an on-sale lasts minutes and a door lasts twenty, both in front of the people who paid.

This page covers that workflow. Platform choice and gateway fees sit on the e-commerce route, the mechanics of taking money belong to payment and checkout, and deeper payment-event testing is a separate task with its own guide still to be published here.

Settle the event model, capacity and release rules first

Name what you are selling. Free registration, paid admission, allocated seating, general admission and a capacity-limited session are five different builds. A single evening is not a three-day conference where a pass grants entry and each session inside it has its own smaller limit. Decide whether one ticket means one admission or allows re-entry, and whether attendance is capped by the venue, by a licence or by how many people you can actually feed.

Then decide how tiers and release timing behave, because that is where the arguments happen. A tier that closes on a date is a different rule from one that closes after a fixed number sells. Agree what happens when a tier runs out, the per-order cap, the holdback kept aside for sponsors and guest lists, and who may release it late. Write them as rules with owners, because on the night somebody will ask for an exception.

Odoo's event documentation, read on 19 September 2026, is one configured example of how a platform holds this. Its dashboard card shows the event name, the scheduled date, the location, the number of expected attendees and the responsible event manager, and the event form carries a Limit Registrations option for the maximum number of attendees allowed, with separate tabs for tickets, communication and attendee questions. That is one product's arrangement rather than a universal model, and it does not say what should happen when two buyers reach for the last two seats.

Inventory that cannot oversell

Overselling is the failure people remember, and the obvious design causes it. If a seat is only deducted when a payment succeeds, every checkout in progress is invisible and the last ten seats can sell thirty times. The safer shape is a hold taken when checkout begins, an expiry that returns abandoned stock, and availability re-checked against an authoritative figure before confirmation. Payment that confirms late, as bank transfers and FPX routinely do, has to be reconciled rather than assumed.

Two policies then become non-negotiable: one capacity figure, in one place, that the website, the back office and the door all read, and honest behaviour at release, when hundreds submit within seconds and somebody has to be told there are four seats left. Our PestaHub concept prototype shows the strict version, where inventory is a numbered lot on a live floor plan that is either free or gone.

Map the journey from event to admission

The sequence is always the same: event or session, ticket request and capacity decision, payment or registration, entitlement issued, admission recorded, exception resolved. The table follows one deliberately simple example, a single-session event with a fixed assumed capacity and one admission per ticket. Every actor and policy in it is an assumption for illustration, and the last column lists checks to run on your build rather than results anybody has achieved.

Registration, ticket, attendee and admission are four records

Keeping them apart prevents rework. A registration is the purchase context, one order by one buyer. A ticket is the entitlement, the thing that grants entry once. An attendee is a person, with a name and perhaps a dietary requirement or a session choice. An admission is an operational state recorded at the door. One office manager buying six passes creates one registration, six tickets and up to six attendees, five of them unnamed at the moment of payment.

That is where the decisions surface: when the missing names are required, who supplies them, and what happens if they never arrive. Odoo again offers an attributed example rather than a schema, with a Questions tab for attendee questions beside the ticket configuration. For your project, agree the order identifier, the ticket identifier, the attendee identity, the payment state and the admission state, collect only the personal data the door and the organiser need, and decide how long it is kept before you collect it.

The door is where ticketing fails in public

Check-in is judged by people standing outside, and the arithmetic is unforgiving. A scan takes a few seconds, so the number of devices and trained staff sets the queue far more than the software does. Venue wifi is frequently poor, which makes an offline mode and a reconciliation routine scope items rather than extras. A duplicate scan may be a family sharing a screenshot or a genuine re-entry, and your policy decides what the scanner is told.

Our HORIZON 2026 concept prototype demonstrates this end of the chain rather than describing it: three pass tiers through a working checkout with a live order summary, a scannable QR e-ticket issued on purchase, an attendee space for building a personal agenda from a three-track programme, and an organiser back office with a door check-in console where a scan updates the checked-in, remaining and rate figures as it happens, beside an orders ledger with paid and refunded states. It is a prototype built by us, not a client event, and its attendee app runs as a web application rather than a store-published app.

Transfers, resale and refunds when the event moves

Tickets change hands. Decide whether a name change is allowed at all, who may make it, up to what deadline, whether it costs anything, and whether the original code stops working on transfer. Resale is the same question with money attached. If you do not provide a controlled route, an uncontrolled one appears anyway and arrives at your door as somebody holding a screenshot they paid for twice. A capped official resale keeps the entitlement inside your system, which is where the door needs it.

Then plan for the event moving. Postponement, a venue change and cancellation are three policies, each needing a decision on refund, credit or automatic transfer, plus partial refunds when one order covered six people and two cannot come. At that point refunds stop being a support inbox and become a queue that has to reconcile against payment records. Keep the ticket states explicit: held, issued, transferred, cancelled, refunded and admitted.

Scope, ownership and acceptance

Write the scope as a checklist with names against it: event and session content, the capacity source, tier and release rules, registration fields, the payment handoff, the entitlement format, the admission rule and the devices that enforce it, exception policies for duplicates, transfers and refunds, integrations, content ownership after launch, and the acceptance evidence above. Separate the public event site from the operational system behind it, which needs roles, permissions and exception paths of its own.

Three adjacent decisions belong elsewhere. Attendee accounts and organiser logins are accounts and portals. Capacity that repeats, such as classes and appointments, is booking and scheduling. And if the project is really a store that happens to sell a few tickets, start at the e-commerce route instead.

What to bring to a first conversation

Bring the shape of the event, the capacity figure and where it comes from, the tiers and their release dates, how many tickets a typical order contains, whether every attendee must be named, how you want to take payment, and the door plan: devices, staff and the network inside the venue. Bring your transfer, cancellation and postponement policies, or say they are undecided, because deciding them is part of the work. Tell us about the event and we will say what we would build and what we would leave out.