Payments and Refunds Best Practices

Apply This Operating Standard

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, Payments and Refunds Best Practices narrows that work to how to keep payment instructions, balances, refunds, upgrades, transfers, and settlements auditable. Because this is a best practices 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 Good Operation Looks Like

This page is a judgment aid. Use it before and during sensitive work, especially when a action that looks valid on screen could still confuse attendees, staff, reviewers, or support leads. 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, Transfers, Upgrades, 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.

Use The Standard Before You Act

1. Identify the policy or risk behind the task: Begin by naming the Event Management situation, the owner, and the exact item involved in Payments and Refunds Best Practices.
2. Compare the planned action with the standard: 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. Adjust the action before saving if the standard is not met: Keep Payments, Refunds, Transfers, Upgrades, and Settlements in view so the work stays tied to the records or contracts it can affect.
4. Record any exception and who approved it: 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.

Signs The Standard Was Met

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 - Choose the right path. Open the related workflow page and confirm you are working on the correct record or event. This anchors the work to the correct scope before any record changes.
2. Step 2 - Confirm scope and records. Use this best-practice page as a checklist before making changes in /rego/events/manage/payments-config?id=:eventId, /rego/events/manage/refunds?id=:eventId, /rego/events/manage/settlements?id=:eventId. Pause here and confirm the attendee, staff, money, and public-page impact still matches the event plan.
3. Step 3 - Do the operating action. Check policy, permissions, affected people, money, privacy, and communication impact before saving. This keeps the event state understandable before another setting changes.
4. Step 4 - Verify the result. Make the smallest accurate change, then verify Payments, Refunds, Transfers, Upgrades, Settlements show the intended result. The next operator should be able to see why this step was taken.
5. Step 5 - Hand off remaining work. Write down unresolved questions and escalate anything that could affect safety, fairness, money, or trust. This leaves a handoff trail another operator can understand.

Money needs proof

Payment and refund records must be understandable later. A future reviewer should know who paid, what they paid for, what changed, whether a refund happened, and why.

Good finance habits

• Keep payment instructions exact.
• Use consistent proof requirements.
• Match provider reports to dashboard balances.
• Record refund reasons.
• Confirm upgrades update balances.
• Confirm transfers do not create duplicate access.
• Reconcile POS and cash-like payments separately.

Common mistakes

• Changing payment accounts after attendees already paid.
• Refunding without checking settlement state.
• Applying coupon discounts without approval.
• Treating pending payment as paid.
• Forgetting that add-ons and inclusions can affect totals.

Verification questions

1. Question 1. Does the attendee balance make sense? Write the answer before choosing the next action.
2. Question 2. Can finance trace every adjustment? Write the answer before choosing the next action.
3. Question 3. Does the settlement view match source records? Write the answer before choosing the next action.
4. Question 4. Are refunds and transfers explained? Write the answer before choosing the next action.