Skip to main content
A refund policy is a named ladder of tiers — “full refund up to 30 days before, 50% up to 7 days before, none after” — defined once and then applied to ticket types, add-ons, and bundles. Refund policies are listed on Refund policy in the event navigation.
Events are free to attend, so no money moves yet. Paid ticketing is not available yet. Until then, the policy is the published promise: what buyers are told, and what will be enforced automatically once payments are collected. Policies written now continue to apply when paid ticketing is available.

Define a policy

1

Create it

Choose Create refund policy and name it — “Standard refund”, “Non-refundable”, “Early-bird terms”.
2

Build the ladder

Add tiers on the policy’s page. Each tier pairs hours before start with a refund percentage — for example, 720 hours (30 days) → 100%, 168 hours (7 days) → 50%. Anything past the last tier gets no refund.
3

Apply it to sellables

Open a ticket type, add-on, or bundle and pick the policy in its Refund policy field. Each sellable carries exactly one policy (or none — “unspecified”).

One policy, many sellables

The relationship is one-to-many: define “Standard refund” once and apply it to every ticket type it fits. The policy’s page lists everything it is applied to, so the affected sellables are visible before a tier is edited.

Rules to know

  • One policy per sellable. A ticket type, add-on, or bundle cites a single policy — there is no mixing of ladders on one item.
  • The binding is chosen on the sellable’s page, not on the policy’s. The policy page’s “Applied to” list is a read-only view.
  • Archived, never deleted. Retiring a policy archives it; sellables that cited it keep the reference (shown as ”— archived”), and history stays intact. Restore it if needed.
  • Hours count back from the event start, so a ladder written once stays correct if the event date moves.
  • No enforcement yet. Today no refund is computed or paid — amounts are 0. Do not promise buyers automated refunds; the ladder becomes enforcement when paid ticketing is available.
  • Every change to a policy is recorded in its log.
Create “Non-refundable” and “Standard” policies early and apply them when creating ticket types. Adding policies to a live catalogue later is more work.

Ticket types

The main place a policy is applied.

Orders

The purchases a policy will one day govern.