Eventonomy

Check-in Scanner Pro

Pro feature. Available in Eventonomy Pro.

Pro - Check-in requires Eventonomy Pro.

Every attendee ticket carries a QR code that encodes a check-in URL. At the door, a staff member scans the QR with any phone camera and the attendee is checked in automatically, with no app to install and no token to type. The eventonomy-pro/checkin block remains available as a manual fallback (and for hardware readers).

Check-in block showing the token input field, Check in button, and a success result

What You Will Learn

  • How the QR check-in flow works
  • Where attendees find their QR ticket
  • The manual check-in block and its settings
  • What happens on a repeat scan, a refunded ticket, and an attendee's own scan

How QR Check-in Works

  1. The attendee gets a QR ticket. Every confirmed order/RSVP mints a unique check-in token, rendered as a QR code on the order-confirmation card, in the order-confirmation email (as an image, with a plain check-in link as a fallback), and in My Tickets on their dashboard. The QR is self-contained: Eventonomy generates it in-plugin, with no external image service.
  2. Door staff scan it. Someone authorized to manage that event's attendees scans the attendee's QR with any phone camera. The QR opens …/?evnm_checkin=<token>. In practice that means the event's own organizer (the person who created the event) or a site administrator - see Access Control below.
  3. The attendee is checked in through the idempotent check-in service, and staff see a "Checked in" confirmation.

Repeat scans, refunds, and self-scans

  • Repeat scan - a second scan of the same ticket shows "Already checked in" (it never double-counts).
  • Refunded / cancelled ticket - a voided ticket is refused at the door (the check-in returns a 409), so a refunded seat cannot get in.
  • Attendee scans their own code (or anyone without check-in permission / logged out) - they get a neutral "present this at the door" page. No check-in happens and the token is never displayed. This is intentional: only authorized staff can redeem a ticket.

Manual Check-in Block

For hardware readers, or as a backup if a phone camera is unavailable, add the eventonomy-pro/checkin block. A staff member enters (or a reader types) the attendee's token and clicks Check in; the block posts to the Pro check-in REST endpoint and shows the result.

Where to Place the Block

Option 1: Single-event page - add the block to the event's single-event page. Set the eventId attribute to filter check-ins to that event only.

Option 2: Dedicated check-in page - create a page (e.g. /check-in/) and add the block there so volunteers can check in attendees for any event from one place.

To add the block: open the page in the Block Editor, click +, search Eventonomy Check-in, insert, and configure.

Block Settings

Setting Default Description
Event ID 0 The ID of the event to check attendees in to. Leave 0 to accept tokens from any event (multi-event pages).
Show stats On Show a summary line below the result area.
Allow manual entry On Show the token input field and the Check in button. Turn off if you are using a hardware reader that calls the REST endpoint directly.

Access Control

Check-in is authorized per event, and only two kinds of logged-in user can redeem a ticket - both via the QR scan and via the manual block:

  • The event's own organizer, meaning whoever created the event. Ownership alone is enough; they need no WordPress editing permission.
  • Site managers, meaning anyone with the manage_options WordPress capability. On a default site that is the Administrator role only.

Everyone else sees the neutral door page or a "Sign in to check attendees in" notice. Notably, an Editor is not admitted at the door for an event they did not create: Editors have edit_others_posts, but check-in maps to evnm_manage_rsvps, which maps to manage_options.

Changed in 1.3.0. Before 1.3.0, evnm_manage_rsvps mapped to edit_others_posts, so any Editor could redeem check-in tokens on any event. If your door staff are Editors on events they do not own, they will now be refused. Either make the staff member the author of the event, or grant them the Administrator role (or manage_options). Full map: capability reference.

What's Next?

Configure paid ticket checkout with a payment gateway.

Payment Gateways →