Payment and Refund Lifecycle

Follow The Record Over Time

Use this guide when event setup, attendee operations, staff work, payment-adjacent tasks, public pages, or closeout records need a controlled path. In this guide, Payment and Refund Lifecycle narrows that work to how balances, payments, refunds, transfers, upgrades, coupons, and settlements move over time. Because this is a lifecycles page, read it as part of the Event Management learning path rather than as an isolated checklist.

Event records become real-world instructions: what attendees see, what staff do, what money or inventory must reconcile, and what future organizers inherit. Read the page for the decision it helps a person make, then use the steps and checks as a steady path from context to action to proof.

What Changes Across The Lifecycle

This page follows a record from one state to another. Read it as a timeline so handoffs, reversals, and closeout work stay understandable. The intended readers are Finance staff and Event leads. If the guide names a dashboard route, service area, export, or record type, treat that name as a pointer to real operational responsibility.

• Primary surface or service: /rego/events/manage/payments-config?id=:eventId, /rego/events/manage/refunds?id=:eventId, and /rego/events/manage/settlements?id=:eventId.
• Records or contracts involved: Payments, Refunds, and Settlements.
• Main care point: Watch for changing one part of the event without checking attendees, staff, finance, communications, public information, and closeout records.
• Proof worth keeping: event ID, dashboard state, public page, attendee record, payment or refund state, check-in count, roster note, export, and reviewer signoff.

Track Each State Change

1. Find the current state: Begin by naming the Event Management situation, the owner, and the exact item involved in Payment and Refund Lifecycle.
2. Read what must be true before the next state: Use /rego/events/manage/payments-config?id=:eventId, /rego/events/manage/refunds?id=:eventId, and /rego/events/manage/settlements?id=:eventId to connect the words on the page to the screen, file, service route, or record that people actually use.
3. Watch for side effects when the state changes: Keep Payments, Refunds, and Settlements in view so the work stays tied to the records or contracts it can affect.
4. Keep the history clear for the next reviewer: Before handing off, save proof such as event ID, dashboard state, public page, attendee record, payment or refund state, check-in count, roster note, export, and reviewer signoff so the next operator can see what changed and why it was safe to continue.

The Lifecycle Is Clear When

You are ready to use the rest of this page when the purpose, owner, affected information, and proof are all clear enough for a second person to review.

1. Scope is named: The work is tied to the correct page, event, report, route, file, person, or record.
2. Impact is understood: The operator can explain the effect on attendees, staff, money, public pages, communications, and post-event records.
3. Proof is findable: The handoff points to evidence that the next operator can see what changed and why it was safe to continue.

End-to-end operator runbook

Use this numbered runbook when you need to operate this area without getting stuck. Read the purpose of each step, do the action in order, and use the final sentence as the checkpoint before continuing.

1. Step 1 - Anchor the work to one event. Payment starts when a registration, upgrade, add-on, inclusion, dealer package, inventory sale, or POS sale creates an amount owed. This anchors the work to the correct scope before any record changes.
2. Step 2 - Read the operational context first. The attendee or staff follows the configured payment instructions or provider flow. Pause here and confirm the attendee, staff, money, and public-page impact still matches the event plan.
3. Step 3 - Change only the intended event setting or record. Operators reconcile payment evidence against the dashboard amount, account, registration, and attendee. This keeps the event state understandable before another setting changes.
4. Step 4 - Check attendee, money, staff, and public impact. Refunds, partial refunds, transfers, and settlement adjustments must be recorded with amount, reason, and reviewer. The next operator should be able to see why this step was taken.
5. Step 5 - Verify the dashboard and public result. Finance analytics and settlements should be refreshed after source records change. Check the related event records before continuing.
6. Step 6 - Leave a clear event handoff. The lifecycle ends only when amount owed, paid, refunded, settled, and exported totals agree. This leaves a handoff trail another operator can understand.

Lifecycle overview

Stage	Meaning	Verify
Amount due	Registration or add-on creates a balance.	Price and inclusions are correct.
Payment submitted	Attendee pays or submits proof.	Provider/account and proof rules match config.
Payment reviewed	Staff confirms payment.	Balance updates correctly.
Adjustment	Upgrade, transfer, coupon, or manual correction changes amount.	Reason is recorded.
Refund requested	Money needs return or cancellation.	Eligibility and settlement state checked.
Refund completed	Refund action is recorded.	Amount, reason, and target are clear.
Settled	Finance reconciles event records.	Dashboard and provider totals make sense.