Find the information you need.

Help with an event

Check the current event guide for resources, FAQs, arrival directions and published assistance contacts. Contact the organizer through its own published channels when you need a conversation.

Your plans and saved events

Saved events and follows, saved plans and private notes and tasks help you prepare. These records do not register you or guarantee admission.

Account update preferences control indicators for published-guide changes.

Account access

Your credentials work on all three portals, with a separate sign-in on each. Event records remain on the portal where the event was created.

Sign in or review account recovery availability.

For organizers

Use registration forms to collect information needed for a defined event task. Text answers, vendor descriptions and applications are supported. The platform does not provide chat, correspondence threads, attendee feedback, ratings or public reviews.

Organizers set itemized taxes, fees and shipping. These organizer charges are separate from platform sales fees: the platform percentage and per-item tariff are invoiced to promoters monthly. Promoters may absorb platform fees or pass them through as a separate buyer charge.

Open the workspace

Organization merchant accounts

Merchant connections and payments remain disabled during development. An organization uses one Stripe account and one Square account across all three portals. Organization owners manage the connection; event records and monthly invoices remain separate by portal. Each Square merchant account belongs to one platform organization. Use that existing organization across the portals; disconnection preserves its financial identity binding.

Provider setup and payment forms prepare a private link; use the explicit provider link to continue. Preparing or opening a link does not confirm payment, extend a stock hold or accept an agreement on your behalf. For Square, the owner starts authorization, signs in at Square and returns to the initiating portal to confirm the account. Attempts expire after ten minutes. When local retention maintenance is enabled, it clears staged credentials from expired, unconfirmed attempts and records a system audit. This bounded cleanup does not contact Square or change completed connections, payments or admission. Cleanup and its optional schedule remain disabled during development. Reauthorization renews the same merchant identity; it does not silently replace the account. A provider return does not enable checkout, confirm payment or grant admission.

An organization owner may request a fresh list of eligible Square locations. Discovery does not select a payment destination or change an order. Only active locations with USD card processing are offered; payment requires fresh verification of the chosen location.

Square credential renewal and disconnection controls are also disabled during development. Disconnection stops local credential use across the organization before requesting Square revocation. Earlier provider requests and uncertain responses require a short retry period; retained orders and sold rights are preserved. Renewal does not replace the merchant identity or confirm payment. If Square reports that this application authorization was revoked, local credentials are cleared and an owner can reconnect the same merchant account. Orders, payment records and sold rights are preserved. Revocation handling remains disabled during development. Automatic renewal also remains disabled. When separately enabled, a bounded system worker renews existing grants after seven days or with one day remaining, identifies its own audit actions, and never connects a new merchant. Failed renewal remains visible, retries have a cooldown, and operators must monitor unavailable or unfinished batches.

Square payment locations are selected per event by an organization owner. The organization account stays shared, while different events may choose different eligible locations within it. Checking locations does not select one. A saved destination records a version for future checkout; it does not guarantee current payment readiness or change an existing order's destination. Review a new version after event settings change. Location selection also remains disabled during development.

After payment activation, a verified full refund can also establish eligibility for platform-fee credits under the original sale terms. If it is verified before its separate refund notice arrives, the credit uses the America/Chicago month of verification. Later notices do not create another credit. Partial refunds require item and charge attribution, followed by a separate platform financial-owner approval of any calculated fee effect. Original discounted prices and frozen category refund policies apply; a refund of passed-through platform fees alone earns no credit. An approved zero-credit review can also resolve the accounting hold. Corrections preserve history and reconcile in the next unfinalized month. If a later verified full refund clears an earlier partial-refund review, its credit stays in the later verification month. Attribution and fee approval remain disabled during development and do not transfer money or change admission. Finalized statements remain unchanged; late adjustments and carried credits stay within the same organization and portal.

PayPal refund review totals authenticated individual refund receipts. A freshly verified full-refund capture status can establish completion before all separate notices arrive; earlier receipt amounts stay unchanged. Partial attribution and fee approval use original prices and fee terms. A later reversal prevents new partial-refund approval while preserving prior financial history. PayPal observation recording and all related operational controls remain disabled during development.

Stripe can verify a full cumulative refund before all individual notices arrive. Original receipts and their recorded status stay unchanged; the later full verification is separate. For partial refunds, the platform financial owner attributes the cumulative refund to original items and charges, then separately approves its combined fee effect with current final dispute-loss allocations. The combined calculation rounds once per order and includes earlier approved credits. Later full refunds deduct those credits and never rewrite finalized statements. Complete verified refund evidence can also settle an earlier partial-dispute review. Stripe observation recording, attribution, financial approval and payment activation remain disabled during development.

Customer payments go directly to the organizer's merchant account. Provider processing charges and organizer itemized charges are separate from platform sales fees, which are invoiced monthly. Promoters may absorb platform fees or pass them through as a separate disclosed buyer charge.

Session places and reserved seating

An availability review or private quote does not reserve a place. The order reservation must check the same selected places again. If a selected place is no longer available, review a fresh selection. Best available does not guarantee adjacent places.

Named seats and unassigned section capacity are separate. A new hold cannot run past the session end. Stock protected by an unfinished external checkout still requires verified closure before release. A seat placement by itself does not grant event admission.

New private seat-linked stock records retain original purchased unit numbers. Partial fulfillment, cancellation or return must identify the exact original units; acting on every eligible remaining unit can be recorded as one batch. Other units keep their original numbers and places. Active holder records on affected units must be reviewed and revoked before release. Older aggregate records retain their original conservative controls. These stock actions do not themselves issue refunds or admission, and do not assign one place to every person in a bundle.

An included session place keeps the product’s original fee category, including Photos and Experiences. A promoter may choose one original beneficiary group and position within each purchased unit. Only that position receives its unit’s place description; other people in a bundle do not receive copies. Earlier records receive no guessed beneficiary. The binding does not establish identity, confirm payment or grant admission.

A signed-in buyer’s reviewed session places must remain exact through order preparation, including best-available seats. If a reviewed place is taken, the buyer must review a fresh selection; the platform does not silently choose replacements. A review holds no stock. Any later stock hold must end by the session end, and provider checkout still needs its own compatible deadline.

A promoter may explicitly include one session entry or re-entry during its scheduled interval for one original attendee position per purchased unit. New session-place configurations default to a place description with no session entry, and retain their original start, end and timezone. Earlier purchases receive no inferred session-entry terms. General event admission stays separate. Session credentials and session-specific check-in remain disabled while development continues.

Session ticket codes have a separate type from general event admission. The original promoter rules control who can retrieve or replace them and whether the accepted attendee must present a live account screen. Live session proof lasts at most 45 seconds and ends no later than the original session end. Replacing a code preserves its original session place and entry allowance; revoked or transferred codes do not revive when a holder is restored. Current stock, payment and access checks still apply. Session codes and scanning remain disabled during development.

Session check-in targets one selected session. A fresh recording checks the original entry window, remaining allowance, current code and payment/access status. Replacements and accepted transfers do not reset usage. Staff must check actual space for tickets subject to capacity; the software does not verify physical occupancy or identity. Previewing a code grants no entry. An earlier receipt never authorizes another entry, and a missing receipt does not prove an interrupted check-in failed. After an uncertain result, keep its reference and ask the organizer to review before another submission. Session check-in remains disabled during development; its online screen requires a connection.

Supplemental live session presentation proofs use a separate signed format and expire within 45 seconds, no later than the original session end. Only the currently accepted attendee may obtain them under the promoter’s current permission. Authentic proof alone grants no entry, current validity, device approval or identity verification. Offline session check-in remains disabled during development; the online scanner still checks current server records.

Offline session check-in requires explicit session-purpose device approval by an organization owner or editor, a bounded authorization of 1–24 hours (default eight), and a signed snapshot of the selected session’s original rights and usage. General event admission approval does not cover sessions. Offline devices cannot immediately see access changes or scans elsewhere. Staff must confirm capacity; live-account presentation rules still apply. The first eligible single-entry observation reconciled counts, with later duplicates flagged for promoter review. Reconciliation does not restore revoked access. Encrypted pending observations must be retained after an uncertain result and reconciled promptly. These operational controls remain disabled.

Public seating purchases and their buyer fulfillment remain disabled during development. Promoters can continue planning internal placements.

Original purchase preparation

Automatic preparation remains disabled during development. When separately enabled, new confirmed paid orders and completed wholly free orders can prepare their original attendee positions in bounded batches. Existing records, including revoked positions, are retained; retries do not duplicate them or restore access. Original purchased places and promoter rules still apply.

Preparation does not assign attendee identities, issue ticket codes, confirm current ticket validity, authorize entry or record collection of included items. If a run needs review, the original purchase record remains available and organizers can use their ordinary preparation controls. Another purchase is not needed to retry preparation.

Recover saved offline session records

Recovery remains disabled during development. When separately enabled, signed-in scanning staff can review and export their own pending browser records for the current portal, including after an appointment ends. This does not reopen event records or renew scanning permission.

A current organization owner or editor explicitly reviews the file for its original event and portal. Verified imports retain the original scanner attribution and separately record the reviewing organizer. Exact retries do not count entry again; later duplicate observations remain flagged. Device-reported times and identity are not independently verified. Importing history does not restore ticket rights or authorize entry now.

Exports exclude signing keys, raw ticket codes and attendee snapshots. Export and import retain the original local queue and file, including after an uncertain response. Keep those copies until the organizer verifies the records. Recovery does not send a message or deliver the file to another person.

Initial bearer ticket codes

Automatic initial bearer-code processing remains disabled during development. When separately enabled, it can create the first code for an eligible original bearer position after completed preparation and verified funding. Existing codes and revoked positions are retained; this process never replaces or revives them. Named and signed-in attendee tickets keep their assignment requirements, and session codes remain separate.

Interrupted work resumes in bounded batches. Changed or unverifiable funding, rights or authority stops the run for organizer review. Historical status counts do not confirm current ticket validity. Original promoter retrieval and replacement rules still apply. This process does not send a ticket, assign an attendee, authorize entry or record collection. Your original purchase remains available if its processing status needs review.

First codes after attendee assignment

Initial assigned-code preparation remains disabled during development. When separately enabled, a new purchaser initial naming or designated account initial acceptance can prepare its first eligible general-admission code. Offers, transfer approvals and historical retries do not create one. Original promoter retrieval, presentation and replacement rules still apply.

Existing and retired codes are retained. Later transfers keep their separate replacement workflow. A valid assignment may remain recorded while its code needs organizer review; the original purchase and ordinary authorized controls remain available. This process does not verify identity, send a ticket, authorize entry or record collection. Older assignments and session-code automation remain separate.

First session codes after attendee assignment

Initial assigned-session-code preparation remains disabled during development. When separately enabled, a new purchaser initial naming or designated account initial acceptance can prepare the first code for an explicitly included original session-entry position. The original session must not have ended. Other bundle positions receive no inferred session entry or copied place.

Original promoter retrieval, presentation and replacement rules still apply. Existing and retired session codes are retained. Offers, transfer approvals and historical retries do not create one; later transfers keep their separate replacement workflow and usage history. A valid assignment may remain recorded while its session code needs organizer review. This process does not verify identity, send a ticket, grant general admission or authorize session entry. Older assignments and bearer-session automation remain separate.

Initial bearer session codes

Automatic initial bearer session code processing remains disabled during development. When separately enabled, its independent worker can prepare the first code only for an explicitly included original bearer session-entry position after original purchase preparation and current verified funding. One purchased unit retains its original beneficiary; other people in a bundle receive no inferred session place.

Processing uses bounded, atomic batches. Existing or retired session codes are retained, ended original sessions are skipped, and named or account-bound positions follow their separate assignment workflow. Current refunds, disputes and access restrictions still apply. Original promoter retrieval and replacement rules remain in force. Historical processing counts do not prove current validity, identity or entry. The worker neither sends tickets nor grants general admission, authorizes session entry or records pickup. Its activation and schedule remain independent from general ticket-code processing.

Reviewing missing first ticket codes

Promoter-reviewed first-code batches remain disabled during development. When separately enabled, organization owners and editors can choose general-admission or session codes and explicitly prepare missing first codes in bounded batches. Existing named or accepted account assignments, current original funding and original promoter retrieval, presentation and replacement rules apply. Unassigned positions are deferred; existing and retired codes are retained, never replaced or revived.

A session place belongs only to its original purchased beneficiary, and ended original sessions receive no new session code. The workflow does not replay an old assignment, guess or transfer an attendee, retrieve or send a ticket, verify identity, authorize entry, record pickup or process payment. After an uncertain connection, retry the exact reviewed batch or review current authorized records; uncertainty does not prove that preparation failed. Outdated first attempts require a fresh review.

Included event admission for a session

A promoter may require the session’s same original beneficiary position to have general event admission included in that purchased item. The default is no prerequisite. Other beneficiaries, matching names or accounts, and separate orders do not satisfy this option. It adds no purchase, charge or refund and does not change earlier purchases.

New online entry checks current funding and eligibility, an active original general ticket, and the original admission dates in their recorded timezone. Already-used general entry can qualify; session entry does not use or reset general entry. The session code may be prepared before the general code, but a new entry needs the active general code.

A new offline snapshot captures current eligibility and the original general-admission calendar. Each observation must fall on an included local date. Reconciliation checks captured historical evidence after later changes; it does not claim current validity. An earlier receipt remains evidence of its original recording and never grants another entry.

Admission-prerequisite activation remains disabled during development. Required tickets fail closed for new online entry and new offline snapshots while it is disabled. Retrieval, presentation and identity rules remain unchanged.