Cancellation

Cancellation and refund are different acts. Cancelling ends participation — it stops sales, invalidates admission, and creates obligations; refunding moves money. Keeping them separate means a goodwill refund cannot accidentally cancel an entry.

The operationsCopy Anchor Link

There is no CancelOrder action. Refunding an Order is RefundMoney; it leaves every Registration confirmed.

Cumulative non-failed refunds against one Order can never exceed its grand total. That ceiling is enforced inside the refund transaction, not by a client check.

Cancelling an EventCopy Anchor Link

Event cancellation commits the lifecycle change first, then applies the participation and money consequences. The flow is:

1. 1

   Mark the Event cancelled. The schedule state becomes cancelled; checkout, payment-intent creation, and approval decisions stop.

2. 2

   Deactivate every Pass and cancel every confirmed and pending Registration. Pending Orders are cancelled, inventory holds released, and coupon reservations released.

3. 3

   Refund every confirmed paid Order in full. The system refund path returns the entire remaining Order total, including the platform fee and its tax.

4. 4

   Reverse the ledger. Organizer payable, organizer tax, Ulsav revenue, and Ulsav tax are reversed against provider clearing. A negative position makes payoutable zero; payouts stop because there is nothing payable.

5. 5

   Append the activity entry and outbound events.

6. 6

   Queue one cancellation message per buyer Order. Delivery runs asynchronously.

The cancelled state is the durable intent. If a provider refund fails, the Event stays cancelled, the failure is counted, and the worker retries the participation and refund side until every paid Order is returned. A message or provider outage never leaves Registrations active.

Two rules bound it.

• The balance may fall short. All Registrations are cancelled regardless. A shortfall leaves refunds to retry; there is no manual approval queue for them.
• Cancellation is irreversible. A repeat edition is a new Event.

Cancelling a PassCopy Anchor Link

There is no organizer Pass-cancellation operation. A Pass can be deleted only while its Event is a draft, and a published Pass is never deleted.

A Pass becomes inactive only when its Event is cancelled. That is what makes its sale state read cancelled. It does not change Orders, refund money, or invalidate Registrations on its own; Event cancellation does all three.

To stop selling one Pass while keeping the Event live, move its sale window or pause Event sales. Neither is a Pass cancellation.

TimingCopy Anchor Link

Two timing rules apply.

Policy is a cap, not an approval. The platform-wide direct-refund cap is the only configurable monetary policy inside the refund transaction. An amount above the cap is rejected with a policy error; it is never queued for approval. There is no per-Organization refundable percentage and no refund window.

A refund is recorded submitted before the provider call, then converges on a terminal state:

stateDiagram-v2
  [*] --> submitted
  submitted --> processing
  submitted --> succeeded
  processing --> succeeded
  processing --> failed
  processing --> cancelled
  succeeded --> [*]
  failed --> [*]
  cancelled --> [*]

requested exists in the database constraint but the direct refund path never writes it.

Postponement carries no refund window. Postponing keeps every Registration and Order, records a revision, and publishes a notice. It does not offer a refund-request window and does not queue a message.

Cancellation itself has no window: once the Event is cancelled, the full refund obligation exists for every paid confirmed Order.

Reassigning instead of refundingCopy Anchor Link

A generic Switch operation moves one confirmed Registration to another Pass, possibly in another Event of the same Organization. It cancels the source and creates a destination Registration against an adjustment Order, optionally refunding up to the source's settled value.

It is not a cancellation alternative. Event cancellation cancels every Registration before any switch could run, and a switch requires a confirmed source. BulkReassign likewise selects only confirmed Registrations, so after an Event is cancelled there is nothing left to reassign.

Cancelling one entryCopy Anchor Link

CancelRegistration invalidates that Registration and the future admission of every Participant in it. It accepts zero, partial, or full refund under the cap.

Capacity is derived from confirmed Registrations and active Participants, so cancellation frees the place immediately. There is no resale policy to satisfy.

A buyer may cancel their own Registration. Cancelling a line on a paid Order without a refund requires registrations.cancel, and attaching a refund additionally calls the refund path, which requires payments.refund. A buyer holding neither capability cannot cancel paid admission through this operation; a free Registration has no such check.

Removing one person from a team is a roster operation, not a Registration cancellation. A replacement starts with the answers supplied for the new person, not the removed person's answers, and is refused once the removed Participant has been admitted. The removed Participant's answers and CheckIn history stay on the removed row.

What Participants are toldCopy Anchor Link

Event cancellation queues one transactional message per buyer Order. It states the cancellation and the refund outcome; the amount is read at send time, so a retried refund is reflected instead of the message claiming money that has not moved.

Postponement, rescheduling, and relocation do not queue a message. They append a public revision that becomes a Notice on the public Event page.

There is no notification preference for a cancellation message. A recipient with no usable address has delivery suppressed, and the refund proceeds regardless.

What money doesCopy Anchor Link

• A refund's amount and terms never change. Only its status and provider references advance. Ledger entries are append-only; a correction is a compensating entry.
• Cumulative refunds cannot exceed the Order grand total.
• A refund returns the Ulsav platform fee proportionally. A full refund returns the whole fee and its tax; a partial refund returns the same fraction of the fee.
• Provider processing costs are not recorded as a ledger category. The chart allows a provider_cost entry, but nothing writes one.
• Each seller issues its own credit note against its own invoice. A full refund of a paid Order with a platform fee produces one organizer credit note and one Ulsav credit note.

RelatedCopy Anchor Link

• Orders — snapshots and the refund ledger
• Pricing and tax — what a refund has to reverse
• Event status — cancellation among the other transitions