Registration Lifecycle

Overview

Registration is the lifecycle of an attendee’s place in the event. It begins with what the event allows the attendee to choose, then continues through payment, confirmation, changes, check-in, cancellation, and post-event records.

Registration staff should think of each rego as a record with access, money-adjacent state, entitlements, and fulfillment attached. Changing a tier is not just changing a label. It can affect capacity, Discord roles, ZEP access, inclusions, payment due, refund eligibility, inventory claims, and check-in.

Dashboard routes

Route	Purpose
/ems/manage/rego-config?id=:eventId	Defines what registration allows.
/ems/manage/regos?id=:eventId	Reviews and manages attendee registrations.
/ems/manage/gifts?id=:eventId	Reviews gifted rego payments, receiver visibility, receiver messages, and redemption state.
/ems/manage/waitlist?id=:eventId	Manages queued attendees when capacity or tier availability is limited.
/ems/manage/upgrades?id=:eventId	Reviews upgrade requests and payment/finalization state.
/ems/manage/transfers?id=:eventId	Reviews requests to move a rego to another attendee.
/ems/manage/refunds?id=:eventId	Handles refund requests that change the financial outcome of a rego.

Flowchart

flowchart TD
  config["<b>Registration available</b><br/>Windows, tiers, add-ons, inclusions, gifting, capacity, and entitlements are configured<br/><i>Surface: Rego Config</i>"] --> submit["<b>Attendee submits rego</b><br/>Reference, identity, tier, add-ons, and initial status are created<br/><i>Surface: Regos</i>"]
  config --> gift["<b>Gift purchased</b><br/>Gifter selects tier/add-ons, pays, may add message, and receiver is notified<br/><i>Surface: Gifts</i>"]
  gift --> giftConfirm{"Gift payment confirmed by event behavior?"}
  giftConfirm -- Staff/manual review --> pendingGift["<b>Awaiting gift payment confirmation</b><br/>Staff review proof before receiver redemption is allowed<br/><i>Surface: Gifts</i>"]
  giftConfirm -- Good faith or confirmed --> redeem{"Receiver redeems gift?"}
  redeem -- Yes --> submit
  redeem -- No --> pendingGiftReady["<b>Ready unredeemed gift</b><br/>Receiver visibility, message, and capacity reservation are tracked until redemption<br/><i>Surface: Gifts</i>"]
  submit --> payment{"Needs payment or staff review?"}
  payment -- Yes --> pending["<b>Awaiting payment or review</b><br/>Check amount, account, proof, and confirmation behavior<br/><i>Surfaces: Regos, Payments Config</i>"]
  pending --> confirmed["<b>Confirmed</b><br/>Status, payment, entitlements, and included items match selections"]
  payment -- No --> confirmed
  confirmed --> changes{"Change requested?"}
  changes -- Waitlist --> waitlist["Waitlist queue, offer window, and communication state<br/><i>Surface: Waitlist</i>"]
  changes -- Upgrade --> upgrade["Upgrade request, approval, payment window, and finalization<br/><i>Surface: Upgrades</i>"]
  changes -- Transfer --> transfer["Transfer request, recipient, identity check, and decision notes<br/><i>Surface: Transfers</i>"]
  changes -- Refund --> refund["Refund request, review, proof, and financial outcome<br/><i>Surface: Refunds</i>"]
  changes -- No --> checkin["<b>Checked in</b><br/>Entry action, operator, flags, and checklist state are saved<br/><i>Surface: Check-In</i>"]
  waitlist --> confirmed
  upgrade --> confirmed
  transfer --> confirmed
  refund --> archive["<b>Archived</b><br/>Open requests, payment questions, and fulfillment claims are closed or assigned"]
  checkin --> archive
  click config "../surfaces/rego-config/" "Open Rego Config surface docs"
  click gift "../surfaces/gifts/" "Open Gifts surface docs"
  click pendingGift "../surfaces/gifts/" "Open Gifts surface docs"
  click pendingGiftReady "../surfaces/gifts/" "Open Gifts surface docs"
  click submit "../surfaces/regos/" "Open Regos surface docs"
  click pending "../surfaces/regos/" "Open Regos surface docs"
  click waitlist "../surfaces/waitlist/" "Open Waitlist surface docs"
  click upgrade "../surfaces/upgrades/" "Open Upgrades surface docs"
  click transfer "../surfaces/transfers/" "Open Transfers surface docs"
  click refund "../surfaces/refunds/" "Open Refunds surface docs"
  click checkin "../surfaces/check-in/" "Open Check-In surface docs"

Lifecycle states

State	What it means	Surface to inspect	Proof before handoff
Available	The event and selected products can be chosen by attendees.	Rego Config	Windows, capacity, prices, inclusions, and entitlements are correct.
Gifted	A paid entitlement exists for a receiver, but no real rego exists until the receiver redeems it.	Gifts	Receiver username, gifter audit record, receiver visibility, optional message, payment state, tier/add-ons, and capacity behavior are visible.
Started	Attendee has created or submitted a rego.	Regos	Reference number, attendee identity, tier, add-ons, and status are visible.
Awaiting payment or review	The rego needs payment proof, staff confirmation, or manual action.	Regos, Payments Config	Payment method, amount, account, and confirmation behavior are known.
Confirmed	The rego is accepted for the event under current rules.	Regos	Status, payment state, entitlements, and included items match the attendee’s selections.
Waitlisted	The attendee is waiting for capacity or offer handling.	Waitlist	Queue, tier, offer window, and communication state are visible.
Changed	The attendee requested an upgrade, transfer, or refund.	Upgrades, Transfers, Refunds	Request status, reviewer notes, and payment/refund impact are recorded.
Checked in	Staff have verified attendance on event day.	Check-In	Check-in time, operator, flags, and checklist state are saved.
Archived	The event is over and the rego remains as a historical record.	Post-Event Record Maintenance	Open requests, payment questions, and fulfillment claims are closed or assigned.

What can change a rego

Change	What it affects	Where to verify
Tier change	Price, capacity, inclusions, Discord/Telegram/ZEP access, and badge or fulfillment expectations.	Regos, Rego Config
Add-on change	Price, inventory, fulfillment, entitlements, and claim records.	Regos, Inventory Tracking
Gift redemption	Creates the receiver’s actual rego from the gift tier/add-ons and the receiver’s own attendee details and form answers.	Gifts, Regos
Upgrade approval	Payment due, final tier/add-on set, and capacity reservation.	Upgrades
Transfer approval	Ownership, attendee identity, contact, and check-in eligibility.	Transfers
Refund approval	Money-adjacent records and attendee-visible outcome.	Refunds
Manual payment update	Confirmation state and whether the attendee can be treated as paid.	Regos, Finance Analytics

Handoff rule

When passing a rego to another operator, include the event ID, rego reference, attendee name, current status, payment state, pending requests, and the exact surface where the next action lives.

Attendee-facing availability and recovery

The public site distinguishes five availability states: Open, Prefill open, Upcoming, Sold out, and Closed. The event-wide window and any tier override are evaluated together, so support staff should check both before treating the public label as incorrect. A prefill is a saved draft, not a reservation or payment.

If a newly created group registration does not appear immediately, the attendee flow retries the authoritative group detail before showing a recoverable sync error. Do not ask the attendee to create a second group while the first request may have succeeded. Gift-registration pages likewise expose load failures instead of remaining on an indefinite spinner.

Legacy attendee accounts must correct a missing or invalid phone number before continuing through protected registration actions. Phone validation uses the selected country and produces a normalized international value; a country-code mismatch requires explicit confirmation. Barangay is required only when the selected country is the Philippines.

Pawsport enrollment is attendee self-service from the account settings surface. Support should record the event, attendee username, safe error text, and whether the document is unassigned, expired, lost, or already claimed. Never request a full NFC credential or other reusable secret in a support message.

Transaction details show the payment method using its configured brand/custom label and show the terms snapshot that applied to that registration, Dealers Den registration, or shop order. A legacy record may state that no historic document body was retained; staff must not substitute the event’s current terms and imply they were historically accepted.

Common mistakes

Do not approve a registration change without checking its side effects. A gift is not a real registration until the receiver redeems it, and the gifter’s details must never be copied into the receiver’s rego. A transfer can change identity risk, an upgrade can change capacity and payment, and a refund can leave check-in or inclusion records out of sync if it is handled only from one screen.