Status overview
Each registration in tikento goes through a chain of statuses. Which steps a registration passes through depends on the event settings: whether email verification is enabled, whether moderation is required, and whether the event is paid.
All possible statuses
| Status | System name | Description |
|---|---|---|
| Pending verification | pending_verification | Participant submitted a registration but has not confirmed their email yet |
| Pending moderation | pending_moderation | Email confirmed, registration awaiting organizer decision |
| Pending payment | pending_payment | Registration approved, payment not received |
| Registered | registered | All stages completed, participant is registered |
| Cancelled | cancelled | Registration cancelled by the participant or organizer |
| Rejected | rejected | Organizer rejected the registration at the moderation stage |
Transition chains
The order of stages is fixed: email verification (if enabled) -> moderation (if enabled) -> payment (if the event is paid) -> registered. Stages that do not apply to a specific event are skipped.
Free event without moderation
The simplest scenario. If email verification is enabled:
pending_verification -> registered
If email verification is disabled, the participant receives registered status immediately after submitting the form.
Free event with moderation
pending_verification -> pending_moderation -> registered
After email confirmation, the registration enters the moderation queue. If the organizer approves it, the status changes to registered. If rejected, the status changes to rejected.
Paid event without moderation
pending_verification -> pending_payment -> registered
After email confirmation, the system awaits payment. As soon as the payment gateway confirms the payment (via webhook), the status automatically transitions to registered.
Paid event with moderation
The longest chain:
pending_verification -> pending_moderation -> pending_payment -> registered
The organizer first decides whether to admit the participant, and only after approval is the payment option opened.
Who initiates transitions
| Transition | Initiated by |
|---|---|
pending_verification -> next status | System (participant clicked the link/entered the code in the email) |
pending_moderation -> pending_payment or registered | Organizer (approval) |
pending_moderation -> rejected | Organizer (rejection) |
pending_payment -> registered | System (webhook from payment gateway) |
Any status -> cancelled | Participant or organizer |
| Manual status change | Organizer (via participant card) |
Automatic transitions
The system performs transitions without organizer involvement in two cases:
- Email verification. When a participant confirms their email, the system automatically determines the next status: if moderation is enabled —
pending_moderation, if not and the event is paid —pending_payment, if free —registered. - Payment received. When the payment gateway sends a successful webhook, the status changes to
registered.
Manual transitions
The organizer can:
- Approve or reject a registration during moderation
- Manually confirm payment (cash, bank transfer)
- Cancel a registration
- Force a transition to
registered, bypassing intermediate statuses
Where statuses are visible
Each participant's status is displayed in several places:
- Participant list — a colored badge next to the name. The status filter allows you to quickly find, for example, all registrations pending moderation.
- Participant card — full transition history with dates and the initiator of each change.
- Event dashboard — status counts in the summary.
Terminal statuses
The statuses registered, cancelled, and rejected are terminal — no further automatic transitions occur from them. The organizer can return a participant from cancelled or rejected to an active status manually via the participant card.