Registrations and payments — admin

Who opens it: an organizer looking for one person, or finance reconciling what arrived.

What they came to do: find a submission (by reference, name or email), see its state, and — for money — record a payment that came as cash or a cheque, or give some back.

True when they leave: the registration's books add up, and anything they did has a name against it in the audit log.

Decisions already made

• Read-only except for payments. A registration is changed by the person who made it (self-service) or by the rules that own its state machine, never by editing columns in a table.
• New registration opens walk-up registration: the event's form, filled in by a member (walk-up.md).
• Contacts match on email only (Pilot Day, A2). A typed email always wins; the same email in another case is the same contact, and a phone typed now replaces the one on file; a +tag or a dot makes another address; a phone alone never matches, and no email means a contact of its own. The old rule once joined two strangers into one family.
• Every fee is its own column, because the question finance asks is not "what did they pay" but "what did we keep, what did Stripe take, what reached the organizer".
• processor_fee_cents showing zero on a card payment means not read yet, not free, and the table says so — the balance transaction appears a moment after the charge (ADR-013: fees are read, never estimated).
• A manual payment requires the user who recorded it (marked_by_user_id); cash should always have a name against it.
• A refund reverses our platform fee by default and proportionally on a partial, with a toggle for a tenant who keeps it (PRICING §4).
• Refunding does not cancel the registration or void tickets. Quietly invalidating somebody's ticket because a partial refund was issued would be worse than doing nothing.
• The registration's page has Cancel (everyone still coming, with a reason; refunds nothing), Refund (an amount, newest payment first; cancels nobody) and Cancel and refund (cancel-and-refund.md). After any of them, and after Approve, Reject or Promote, the page reloads so its tables are current (Pilot Day, C2, C4).
• A submission that did not finish stays a draft: it was saved, but its tickets could not be issued, so it was never confirmed. Its page says Submission failed — ticket could not be issued, and Retry carries it on as if it had just been made (approval, the waitlist, payment or confirmation, with its tickets). Confirming and issuing always succeed or fail together, so no registration is confirmed without its tickets (2026-09-15).
• Imported people are confirmed with their tickets, so they can be scanned; their confirmation and ticket emails go out only when the import asks for them.
• Only a registration waiting for a decision can be ticked for Approve selected or Reject selected.
• Reference is the short code (the last eight characters, as on the page title); Submitted is in the event's timezone, named.

Open questions

• Should finance see a per-event reconciliation total, or is that a report?
• Partial refunds of multi-attendee registrations have no notion of whose place was refunded.