Payment and Refund Lifecycle

Overview

The payment lifecycle explains how money-adjacent records move through EMS. Furries PH and TarsierDesk do not hold event money. Attendees pay directly into the payment accounts configured by the event team, while EMS records the instructions, proof, confirmation state, refunds, POS transactions, and settlement notes.

Because payment processing is manual or provider-dependent, finance staff must treat every confirmed payment as a record that needs evidence. A green status is useful only when it matches the receiving account, proof, amount, and reviewer notes.

Dashboard routes

Route	Purpose
/ems/manage/payments-config?id=:eventId	Defines payment behavior, providers, accounts, QR images, refund settings, surcharges, VAT, and confirmation behavior.
/ems/manage/regos?id=:eventId	Reviews attendee payment state and manual payment updates.
/ems/manage/upgrades?id=:eventId	Handles payments created by upgrade requests.
/ems/manage/refunds?id=:eventId	Reviews and records refund requests, proofs, decisions, and removal state.
/ems/manage/finance-analytics?id=:eventId	Reconciles provider/account totals and payment records.
/ems/manage/settlements?id=:eventId	Records settlement quotes, proof, notes, and settlement completion.
/ems/manage/point-of-sales?id=:eventId	Records event-day sales and payment method/account choices.

Flowchart

flowchart TD
  setup["<b>Payment setup</b><br/>Providers, accounts, QR codes, fees, VAT, refunds, and confirmation behavior are configured<br/><i>Surface: Payments Config</i>"] --> pending["<b>Payment pending</b><br/>Attendee or operator has an amount due<br/><i>Surfaces: Regos, Upgrades</i>"]
  pending --> submitted{"Proof or payment details submitted?"}
  submitted -- No --> followup["Follow up or keep the request pending with an owner"]
  followup --> submitted
  submitted -- Yes --> review["<b>Payment review</b><br/>Check amount, account, sender context, and event reference"]
  review --> confirmed{"Payment accepted?"}
  confirmed -- Yes --> paid["<b>Payment confirmed</b><br/>Dashboard state and receiving account agree<br/><i>Surface: Finance Analytics</i>"]
  confirmed -- No --> refundPath["<b>Refund or correction needed</b><br/>Review request, fee handling, proof, and notes<br/><i>Surface: Refunds</i>"]
  paid --> pos{"Event-day sale or settlement remains?"}
  pos -- POS --> sale["Record customer, basket, method, account, surcharge, and transaction<br/><i>Surface: Point of Sales</i>"]
  pos -- Settlement --> settle["Record settlement quote, proof, amount, and completion state<br/><i>Surface: Settlements</i>"]
  pos -- No --> complete["Finance record ready for closeout"]
  refundPath --> complete
  sale --> complete
  settle --> complete
  click setup "../surfaces/payments-config/" "Open Payments Config surface docs"
  click pending "../surfaces/regos/" "Open Regos surface docs"
  click paid "../surfaces/finance-analytics/" "Open Finance Analytics surface docs"
  click refundPath "../surfaces/refunds/" "Open Refunds surface docs"
  click sale "../surfaces/point-of-sales/" "Open Point of Sales surface docs"
  click settle "../surfaces/settlements/" "Open Settlements surface docs"

Lifecycle states

State	What is true	Surface to inspect	Completion evidence
Payment setup	The event has a payment policy and at least one active payment path when paid registration is used.	Payments Config	Provider, account, QR, surcharge, VAT, confirmation behavior, and refund settings are saved.
Payment pending	Attendee or operator has a balance that is not yet confirmed.	Regos, Upgrades	Amount due, method, account, deadline, and proof expectation are clear.
Payment submitted	Attendee has provided payment proof or staff has recorded payment details.	Regos	Proof, amount, account, and reference can be checked by staff.
Payment confirmed	Staff accepts the payment as valid.	Regos, Finance Analytics	The receiving account and dashboard record agree.
Refund requested	Attendee or staff has started a refund path.	Refunds	Request reason, target amount, fee handling, and affected items are visible.
Refund reviewed	Staff approves, denies, or records the refund outcome.	Refunds	Decision notes, reference, proof upload, and removal behavior are recorded.
Settled	Finance staff have reconciled event totals and settlement proof.	Settlements	Settlement proof, notes, amount, and completion state are saved.

Configuration choices that affect the lifecycle

Choice	What it changes	Where to verify
Payments enabled	Whether attendee checkout expects payment handling.	Payments Config
Confirmation behavior	Whether regos confirm automatically after submission or wait for manual review.	Payments Config
Surcharge or absorb costs	Whether extra processing cost is passed to the attendee or carried by the event.	Payments Config, Finance Analytics
Cash round-up	How POS or cash-friendly totals are rounded.	Payments Config, Point of Sales
VAT handling	Whether VAT is tracked and whether VAT surcharge is applied.	Payments Config
Refund fee mode	Whether admin fees are retained, waived, or handled per refund policy.	Payments Config, Refunds
Preferred provider/account	Which payment path appears first or is treated as default.	Payments Config

Reconciliation checklist

Check	Why it matters
Provider/account totals match expected registration and POS activity.	Prevents missing deposits, duplicate confirmations, and incorrect settlement numbers.
Manual payment updates have proof or notes.	Prevents unexplained paid statuses.
Refunds have a reference, decision, and proof when applicable.	Keeps finance review and attendee support aligned.
Upgrade payments do not hold capacity forever.	Prevents unpaid accepted upgrades from blocking others.
POS payment method and account choices match actual event-day collection.	Keeps event-day money records usable after closeout.

Common mistakes

Do not mark payment complete just because a screenshot exists. Confirm the amount, account, sender context, and event reference. Screenshots are evidence to review, not automatic proof that funds arrived.