Ticketing had to become an operating fact
Event systems often treat ticketing as an integration detail: a link is added, a provider name is stored, or a payment total appears after sales begin. That is too late for an operations platform. Teams need to know during setup whether admission will be sold through the native system, handled by an external sales operation, or not sold at all. Each choice affects who owns the customer journey, which tools staff use and what the system may legitimately enforce.
Ambiguity also creates poor commercial behavior. Inferring external ticket sales from URLs or imported data is unreliable and invasive. Applying a blanket share-of-sales rule would confuse software entitlement with a commercial arrangement. NOCTRA instead records the organizer's selected mode and applies the corresponding capability at the same authoritative boundary that persists the Event.
Three explicit modes
NOCTRA Ticketing is the native paid-admission path and is available on every plan, including Free. External Ticketing represents an Event whose paid tickets are sold through a separately operated channel and starts with Core. No paid tickets is a precise declaration: the Event sells no paid tickets. It is not a euphemism for an undisclosed external provider, and it does not attempt to classify free registrations, guestlists or Door operations as ticket revenue.
The setup interface uses the same language as persistence so the choice does not change meaning between screen and server. Free workspaces can run paid-ticket Events with native NOCTRA Ticketing, while attempts to persist External Ticketing are blocked unless the effective commercial entitlement includes it. The UI can explain the upgrade path, but it is not the security boundary.
The boundary stays truthful
External Ticketing describes a sales operation outside NOCTRA; it does not make NOCTRA the ledger for that provider. The product can retain the chosen mode and the organizer's external references, but it does not claim checkout, refund or buyer evidence it never handled. Reporting can identify the model without presenting external volume as native transaction data.
The capability begins with Core and remains subject to the Workspace configuration and the member's permission to change the Event. A later plan change does not erase an Event or rewrite its earlier ticketing choice. It limits a new operation that requires External Ticketing while leaving the historical Event record and unrelated editing intact.
A cleaner handoff from planning to Door
Once ticketing mode is explicit, the rest of the Event can depend on a stable premise. Planning surfaces can present the right ticketing context. Door staff can work from the Event's admission model rather than a private note or last-minute explanation. Reporting can distinguish native ticket activity from an externally operated model without claiming data that NOCTRA does not possess.
The mode is intentionally not an external-sales detector. NOCTRA does not scan for provider links, estimate off-platform volume or apply a 10% ticketing rule. Those approaches would create false positives and turn routine Event edits into compliance guesses. The product asks the organizer for the fact it needs, persists that fact, and enforces the commercial capability directly.
Choice without ambiguity
Making native ticketing available across all plans keeps Free operationally complete for teams ready to sell through NOCTRA. Core becomes the starting point when an organizer needs to retain an independent external sales workflow. Higher plans preserve that choice while adding reporting, export or capacity benefits according to Pricing V3; they do not change the meaning of the ticketing modes.
This is a small control with a large effect on clarity. The Event states how paid admission works, and the product applies the relevant plan and permission checks when that choice is saved. Teams can then plan, operate and review the Event with the same commercial fact intact from setup onward.
That clarity also improves support and handover. A new collaborator does not have to inspect links, revenue fields or private notes to understand the intended sales model. The answer is part of the Event, expressed in product language that remains consistent across setup, persistence and later operational review.