What it does

Gives organisers an accurate view of event capacity by separating finished registrations from registration tickets that are still being processed or have gone wrong. The Registration count on the event reflects only successfully created registrations, and a separate pending count shows tickets that aren't finalised. A Pending registration tab lists them and lets you retry or delete.

Key facts

• A registration isn't one step. The system creates a temporary registration ticket to hold the attendee's place while it validates details, fills custom fields, takes payment and allocates passes.
• The Registration and attendance tab lists confirmed attendees with statuses Registered, Waitlisted, Cancelled and Checked-in.
• The pending tab sits under Related on the event, with columns for created on, registration ID, name, email, counts as pending, processing status, failure description and the submitted registration data.
• Counted as pending: In Progress (validation), Payment Pending, Payment Passed, and Failed. The exception is Failed where the registration was created but a later step failed, such as unmapped custom fields.
• Not counted as pending: Registration Created (with one or more custom fields not populated) and Payment Failed.
• Actions on selected tickets: Refresh, Edit, Retry and Delete Ticket. Deleting a ticket releases any capacity reservation.
• For a paid event to reprocess, the event purchase record must have Processed false and Paid true.

When to use / skip

Use it on any event with capacity limits, paid tickets or custom registration fields. If you run small free events without caps, you'll rarely open the pending tab, but it's still the first place to look when someone says they registered and got nothing.

Configuration decisions

• Who works the pending tab during a live registration window, and how often.
• Whether to retry failed tickets in bulk or review the submitted data first.
• How you'll reconcile payment-failed tickets with the finance side before deleting them.
• What your capacity buffer looks like, given pending tickets hold places.

Gotchas

• Capacity can look full when it isn't. Pending tickets reserve places, so a stuck ticket quietly eats a seat until someone retries or deletes it.
• A created registration still counts toward capacity even if the custom field step failed, so your numbers and your attendee data can disagree.
• Retry on a paid ticket can fail if the purchase record isn't in the expected state. Check Processed and Paid before pressing the button.
• Delete is not undo. It frees the seat, but the registrant has to start again.

Consultant notes

• Put a named owner on the pending tab for launch day. Nobody notices failed tickets until the waitlist starts filling for the wrong reasons.
• Test the failure paths in UAT: a bad custom field mapping, a failed payment, a stuck validation. The happy path never shows you this tab.
• Brief the events team that "registered" in the form and "Registered" in the grid aren't the same thing.
• Get the finance owner to agree what happens to Payment Failed tickets before the event goes on sale.

---

Worth revisiting after the next release wave touches event registration or payments.