Setting Up Your Refund Policy | Planadar Help

Setting Up Your Refund Policy

Go to Event Console → Sales & Registrations → Registration Settings → Refund Policy.

The Settings

1. Are tickets refundable? (required) — Choose Refundable or Non-refundable. This is shown to attendees before they buy, and it's what actually determines whether cancelling a paid ticket issues a refund (see below).
2. Refund Deadline (optional, only shown when Refundable) — "Refundable if cancelled at least N days before the event." Leave blank to allow refunds any time up to the event. Once you've sold tickets, you can only make this deadline more generous (fewer days, or removed) — not stricter — so no one who already bought gets a worse deal than they agreed to.
3. Refund & Cancellation Policy Details — Free text describing your terms: fees, how to request a refund, anything else attendees should know. Shown alongside the ticket tiers on your event page, along with the deadline above if you've set one.
4. Require Policy Acceptance — When on, attendees must tick a box accepting your policy before they can complete a purchase.

How Refunds Happen

Automatically, in the common case: when an attendee cancels their own paid ticket from My Profile → Tickets, and your event is set to Refundable (and, if you set a deadline, they're still within it), Planadar issues a full refund to their original payment method via Stripe immediately — no action needed from you. Outside the deadline, or if the event is Non-refundable, cancelling removes their ticket but no refund is issued.

You get an email and in-app notification either way, so you always know when someone cancels and whether a refund went out.

Cancelling Someone's Ticket Yourself

The Cancel Registration action on the Registrations list (Event Console → Sales & Registrations → Registrations) works the same way as the attendee's own cancellation: it follows your Refund Policy setting (refunds automatically if the event is Refundable, no refund if Non-refundable), emails the attendee either way, and can't be used on a ticket that's already checked in.

Refunding From the Revenue Tab — With or Without Cancelling

Go to Organizer Admin → Revenue, find the transaction, and click Issue Refund. The amount starts at whatever is still refundable, and refunding is a separate decision from whether the person is still coming:

• A partial refund keeps their place. A goodwill refund or price adjustment settles money only. Their ticket stays valid, it scans at the door, and their seat stays theirs.
• A full refund asks you what to do with the registration:
  • Refund & Cancel Registration — the money goes back, they come off the attendee list, the seat returns to the ticket tier, the next person on the waitlist is promoted if you have auto-promotion on, and they're emailed that their registration was cancelled.
  • Refund without Cancelling — the money goes back and they stay on the list. Note that a fully refunded ticket is refused at check-in, so only choose this if you plan to admit them anyway (organizers and admins can, and it's recorded).

You can refund more than once, up to the balance. A $299 ticket that already had $50 returned can be refunded a further $249; the dialog shows what's left.

What a Refund Means at the Door

This is the part worth knowing before you refund someone mid-event:

• A partial refund keeps the ticket valid. The attendee still checks in normally, still gets the virtual join link, still scans into sessions. Use this for goodwill and price adjustments.
• A full refund invalidates the ticket everywhere — main check-in, virtual join, and session scans. Staff see a specific reason ("This ticket was fully refunded on Aug 26"), not a generic error, so they can explain it at the desk.

Admitting Someone Anyway

A refused guest is usually a records problem, not a gatecrasher. Organizers and admins scanning at the door get an "Admit anyway" button on a refused ticket; one tap checks the person in.

Committee members and volunteers don't get that button — the same trust level that controls the check-in window override.

Every override is written to the check-in log (Event Console → Event Day → Check-in Activity) with who did it and what the ticket looked like at that moment, shown as an "Admitted by override" badge. You never have to choose between letting a real guest in and keeping honest records.

Session Check-In

Individual sessions follow the same rule. In Session Check-Ins → Attendance Tracker, an attendee whose ticket was fully refunded carries a Refunded badge with the reason, and their button reads "Check In anyway…" — tapping it asks you to confirm before admitting them, and records that you did.

A partially refunded attendee is not flagged at all: that ticket is valid and they're expected.

Scanning on a Phone

On a phone, tap Scan in the bar at the bottom of the screen — the raised button in the middle. It's there for everyone who can check people in: organizers, admins, committee members with check-in access, and confirmed registration-desk volunteers. It opens a scanner built for standing at a door, listing only the events you're allowed to scan for. If you're working a door and don't see the button, ask the organizer to add you to the committee with check-in access or to the registration desk.

Pick the event, then choose what the door is for:

• Event check-in — admits someone to the event, exactly as the desktop scanner does.
• Session check-in — records that they were in a particular room. Choose the session first.

Both read the same ticket. Attendees carry one QR for the whole event; there is nothing extra to issue for sessions.

No camera? If the camera is blocked or a code won't read off a bright screen, tap Scan image and choose a photo or screenshot of the ticket's QR code. It works in both modes.

Every scan is recorded. Session scans appear in the check-in history under Event Day → Check-In, marked with the session's name, next to main-door scans — refusals included, so "we scanned them and it said no" can be checked afterwards. Anyone admitted by Admit anyway is recorded with the refusal that was waived.

A refused ticket behaves the same as everywhere else: it says why, and offers Admit anyway to organizers and admins, recording the decision.

When the Connection Drops (Offline Check-In)

Event check-in keeps working without signal. When you open the scanner and pick an event, it downloads that event's ticket list while it still has a connection. The line under the header tells you: "Offline ready — 120 tickets, synced just now". Open the scanner at the door before the queue starts, while you have signal — a phone that has never downloaded the list has nothing to fall back on.

If the connection drops, scanning carries on from the saved list. Staff see the same messages they would online — "Already checked in", "Check-in is not open yet", a refunded ticket's reason — and a successful scan says "Checked in offline — saved on this device, syncs when back online".

Keep the scanner open. Today the scanner page itself needs a connection to load, so don't close the tab or let the browser discard it mid-event. Locking the screen is fine.

Everything syncs by itself. The line shows "3 scans waiting to sync" until the phone is back online, then sends them automatically and keeps retrying while anything is left — tap Send now to push them immediately. Refusals are sent too, so "we scanned them and it said no" can still be checked afterwards. Check-ins are recorded at the time the person was at the door, not the time the phone reconnected.

Planadar re-checks every offline decision. A saved list can't know about something that changed during the outage — a ticket transferred, refunded or cancelled, or the same ticket scanned at a second door. If the server disagrees with an offline admission, it is not marked as checked in; the scanner shows "1 offline admission was not accepted" with the reason, and the check-in history marks it "Admitted offline · not accepted". (Marking it anyway could turn away the rightful holder of a transferred ticket when they arrived.) Every other offline scan shows an Offline badge there.

If someone signs out — or their session expires — with scans still waiting, the scans are kept on the phone (without attendee names) and send when they sign back in. Nobody else who signs in on that phone sees or sends them.

Session check-in still needs a connection. Offline scanning covers the main event door.

The saved list keeps itself fresh. While it has signal, the scanner downloads the list again partway through its lifetime, so "Offline list is out of date" only appears on a door that genuinely couldn't reconnect.

Organizers can see doors that may still hold check-ins. Each scanner reports in every minute while it has signal. If a door's last report says scans are still waiting, or a door that was in use has gone quiet (it may have lost signal and kept scanning), a notice appears on Event Day → Check-In, on the Attendance Overview, and in the Certificate Designer. Each door listed says which case it is: a silent door sends its scans by itself when it reconnects, while a door that is online but still holding scans keeps retrying every 30 seconds — if that doesn't clear in a few minutes, ask the person on that door to tap Send now, which shows the error if sending keeps failing. Issuing certificates then asks you to confirm first, because anyone still on a door's phone wouldn't get one yet. It's your call: you can always issue again later, and only the people who were missing are added.

Offline Check-In Settings

Each event has its own settings in Event Console → Event Day → Check-In → Settings → Offline Check-In:

• Allow offline check-in (on by default). Turn it off if you'd rather a queue wait than risk admitting a ticket that changed hands during an outage; the scanner then stops while offline.
• Use a saved list for up to (120 minutes by default). After this, the door stops trusting its saved list and waits for a connection. Set it lower if tickets are still being transferred or cancelled on the day.
• Who can admit a refused ticket while offline — only you and admins (the same as online, the default), also committee members and registration-desk volunteers, or nobody.
• What the saved list includes — names only (default), names and email addresses, or neither (the door shows only whether a ticket is valid; the phone is never sent any attendee details).
• Delete the saved list after the event (24 hours by default). The list is also erased when that person signs out.

CE credit, CEU and CME

Staff scans are recorded differently from self check-ins. Every attendance record keeps the method that produced it — a staff scan, an attendee checking themselves in at the door poster, or a manual entry — so if you award CE credit (continuing education, CEU or CME), you can tell which attendance was witnessed by your staff and which the attendee reported themselves.

Planadar records that distinction; it does not calculate CE credit for you. There is no CE hours field, no CE calculation and no CE column on the export today. Export the session attendance from Reports → Sessions, and apply your own accrediting body's rules to it — most require staff-verified attendance, which is exactly what the check-in method tells you.

The scanner's address includes the event and session, so you can bookmark a door station, or send the link to whoever is working that room.

Cancelling an Already Partially Refunded Ticket

Cancelling refunds the balance — what they paid minus what already went back — so nobody is refunded the same money twice, and nobody loses the remainder.