Everything is free today, so no money moves yet. Until paid ticketing arrives, the policy is the published promise: what buyers are told, and what will be enforced automatically once payments land. Writing policies now means your paid launch inherits them ready-made.
Define a policy
1
Create it
Click 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 — e.g. 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 you can see the blast radius before editing a tier.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 you need it back.
- 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 payments ship.
- 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.