# Door Check-In (/docs/live-events/check-in) Every ticket sold through [Resyevents](/docs/live-events/storefront) carries its own QR code. At the door, staff scan a code and Resytech answers one question: should this person be admitted? A valid ticket is admitted and marked used, and a ticket that has already been used, refunded, or voided is rejected with the reason. This is a different mechanism from [activity booking check-in](/docs/bookings/check-in). There are no waivers, guest-info gates, or arrival rosters here. An event ticket is one admission, and scanning it either works or it does not. How Tickets Reach the Buyer [#how-tickets-reach-the-buyer] Tickets are issued when an order is paid, not when it is started. As soon as the payment succeeds, the buyer receives a confirmation email titled `Your tickets for {event name}` containing: * The event name, date, doors time (if set), and venue, all shown in the event's local time zone * A receipt of what they bought and what they paid * **One QR code per admission**, so a four-ticket order arrives with four separate codes Each ticket card in the email shows its number ("Ticket 1", "Ticket 2"), the ticket type name (or "Admission" if the type has no name), and the last eight characters of its code as a short reference you can read out over the phone. The email is the only place a buyer's QR codes appear. The storefront confirmation page tells them to show the code from their email, and organizer-side order views deliberately never display admission codes. If a buyer cannot find their email, direct them to search for the event name rather than trying to read the code off a dashboard screen. One email is sent per paid order. Repeated payment notifications from Stripe will not send duplicate copies. What Staff Do at the Door [#what-staff-do-at-the-door] Scanning a ticket supports two actions, and it is worth knowing which one you are using: | Action | What it does | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Check status** | A read-only look at the ticket. It reports whether the ticket is good, already used, refunded, or voided, and it changes nothing. Use it to answer a question at the front of the line without burning the admission. | | **Check in** | Admits the ticket. On a valid ticket this records who scanned it and when, and the ticket is now used. | Only the check-in action consumes a ticket. A status check never admits anyone and never marks a ticket used, so it is safe to run as many times as you like. Every scan is scoped to your own organization. A ticket sold by another organizer reads as "no ticket found for that code" rather than revealing that it belongs to someone else. If two staff members scan the same single-day ticket at the same instant, only one of them gets an admit. The other gets "already checked in", so a duplicate scan cannot let two people through on one ticket. Scan Outcomes [#scan-outcomes] | Outcome | What it means | What to do | | ---------------------- | --------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Admitted** | A valid, unused ticket. It is now marked used, with your name and the time recorded. | Let them in. | | **Re-entry** | A multi-day pass that was already used earlier. Multi-day events re-admit. | Let them in. | | **Already checked in** | A single-day ticket that has already been scanned. The response tells you when it was first used. | Do not admit. Someone has already come in on this code, either the same person twice or a forwarded screenshot. Check the order in the dashboard before making an exception. | | **Refunded** | The ticket's order was refunded in full, so the ticket is no longer admissible. | Do not admit. The buyer has their money back. Send them to the box office if they dispute it. | | **Voided** | The event was cancelled without automatic refunds, which voids live tickets so they cannot be used at the door. | Do not admit. The event is cancelled. Refunds are handled separately by the organizer. | | **Valid** | Status-check only. The ticket is good and has not been used yet. | Nothing has happened yet. Run the check-in action to actually admit. | | **Not found** | No ticket matches that code under your organization. | Do not admit. Either the code is not one of yours, it is not an event ticket at all, or it was mistyped. Look the buyer up by name or email in the event's [orders](/docs/live-events/orders-and-refunds). | Only **Admitted** and **Re-entry** mean "let this person in". Every other outcome is a stop. Note that a partial refund does not invalidate tickets. If an order was refunded for less than its full amount, its tickets stay valid and will still admit. Single-Day Events and Multi-Day Re-Entry [#single-day-events-and-multi-day-re-entry] Whether a ticket re-admits depends on the event itself, not on a setting you toggle: * If the event starts and ends on the **same calendar day** in its local time zone, tickets are single use. A second scan reports "already checked in". * If the event **spans more than one calendar day** in its local time zone, tickets re-admit for the run of the event. Every scan after the first reports "re-entry" and lets the attendee back in. Two consequences worth knowing before the doors open: * **An event that runs past midnight counts as multi-day.** A show scheduled 9:00 PM to 1:00 AM ends on the next calendar day locally, so its tickets will re-admit. If you need strict one-scan admission for a late show, end the event before midnight local time. * **The event's time zone decides the calendar days.** The comparison uses the event's own time zone, so daylight saving changes are handled correctly. If an event has no usable time zone set, the calculation falls back to UTC, which can classify a late evening show as multi-day. Set the time zone correctly when [creating the event](/docs/live-events/creating-events). On a multi-day event, the recorded check-in time is the **first** admission. Later re-entries admit the attendee but do not overwrite that original timestamp, so the record still shows when the pass was first used. Where Check-In Shows Up in the Dashboard [#where-check-in-shows-up-in-the-dashboard] There is **no scanning screen in the dashboard today**. Ticket check-in runs through the Resytech API, so scanning is done by a device or app pointed at it rather than from a page in the dashboard. What you can see in the dashboard is each ticket's current state. Open the event, go to the **Orders** tab, and open an order: every ticket in it is listed with its type, attendee name, and status (valid, checked in, refunded, or voided). That is the fastest way to settle a door dispute about whether a code was already used. The full per-ticket check-in record, including the time each ticket was admitted, is also part of the [attendee list data](/docs/live-events/sales-and-attendees). Who Can Check Tickets In [#who-can-check-tickets-in] Both the status check and the admit action require the `events` permission, the same permission used for the rest of Live Events. Give it to whoever is working the door. Access is limited to your own organization's tickets. Staff cannot look up, inspect, or admit a ticket belonging to another organizer. Related [#related] * [Sales and Attendees](/docs/live-events/sales-and-attendees) * [Orders and Refunds](/docs/live-events/orders-and-refunds) * [Ticket Types and Add-Ons](/docs/live-events/tickets-and-add-ons) * [Creating Events](/docs/live-events/creating-events) * [Live Events overview](/docs/live-events)