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.
Related
Ticket types
The main place a policy is applied.
Orders
The purchases a policy will one day govern.