Refunds

When an attendee is removed from a paid registration — whether by an admin or by the member themselves — Seva creates a refund automatically and routes it to the specific Stripe payment that paid for that attendee. Refunds are managed centrally on the Refunds page in the sidebar.

How refunds work

• One refund per attendee. Cancelling a registration with three paid attendees creates three refund rows, not one. Removing a single attendee creates one refund row.
• Each refund routes to its original payment. If a registration was paid for in two separate checkouts (for example, the registrant added guests later), each attendee’s refund goes back to the payment that originally covered that attendee. You don’t need to pick the source payment.
• Refunds are created automatically. As long as an attendee is eligible (see below), Seva creates the refund row at the moment the attendee is removed.

When refunds are created

A refund row is created for each removed attendee unless one of the following applies:

• The attendee is free — ticket price is $0 and no late fee was charged. No refund row is created.
• The attendee has already been refunded on a prior removal attempt. No second row is created (this prevents double-refunding).
• The event’s refund deadline has passed. The attendee is still cancelled, but no refund row is created.

Late-fee-only attendees (price $0 plus a late fee) do get a refund row for the late-fee amount.

Removing attendees

There are two ways an attendee can be removed.

Cancelling a whole registration

1. Open the registration detail page.
2. Change the Status dropdown to Cancelled.

One refund row is created per paid attendee on the registration, each routed to its original payment. Free attendees are cancelled with no refund row.

For more on registration statuses and the registration detail page, see Managing Registrations.

Removing some attendees

The Remove action lets you cancel a subset of attendees while leaving the rest of the registration in place. Use it when:

• A member needs to drop a guest but stay registered themselves.
• An admin needs to remove a specific no-show or duplicate attendee.

1. Open the registration detail page.
2. Find the attendees table.
3. Click Remove next to each attendee you want to cancel.
4. Confirm in the dialog. The dialog tells you whether a refund will be created.

The attendee cancellation and the refund row are written in the same database transaction, so you never see a cancelled attendee without its refund row, or vice versa.

The Refunds page

Open Refunds in the sidebar. The page has two sections.

Pending refunds

Refunds awaiting admin approval. This section is only populated if your organization has Require Refund Approval enabled — see Refund approval setting below.

Each row shows:

Column	Description
Registrant	The person who registered.
Attendee	The specific attendee this refund is for.
Amount	The refund amount.
Reason	Why the attendee was removed.
Date	When the removal happened.

Two actions per row:

• Approve — sends the refund to Stripe immediately.
• Deny — rejects the refund and prompts you for a denial reason.

Rows are grouped by registration so you can see all refunds for a single cancellation together.

Failed refunds

Refunds that Stripe rejected. Each row shows the failure reason where Stripe provided one. Two actions:

• Retry — resubmits the refund to Stripe.
• Deny — gives up on the refund (for example, if you’ve already refunded the customer out-of-band in the Stripe dashboard).

A failure on one row never blocks the others. Each refund is processed independently.

Refund approval setting

A single organization-level setting controls whether refunds need admin approval before being sent to Stripe.

• Require Refund Approval: ON (default). Every new refund row is created in Pending status. An admin must Approve it on the Refunds page before Stripe is contacted. Use this if you want a chance to review every refund before it goes out.
• Require Refund Approval: OFF. Every new refund row is created in Processing status and sent to Stripe immediately. The Pending section will be empty.

Toggle the setting in Settings → Organization.

The setting only affects newly-created refunds. Refunds already in Pending stay there until you approve or deny them, even if you turn approval off.

Refund statuses

Status	Meaning
Pending	Awaiting admin approval (only when Require Refund Approval is ON).
Processing	Being sent to Stripe.
Processed	Successfully refunded by Stripe.
Denied	An admin rejected this refund.
Failed	Stripe rejected the refund. Retry or deny it from the Refunds page.

Member self-service: guest removals

If your site uses Seva’s embeddable web components, members can remove their own guests from upcoming registrations through the <seva-my-registrations> component. When a member does this:

• A refund row is created for each removed guest, following exactly the same eligibility rules as admin-initiated removal.
• The registrant receives an email with the subject “Guest cancelled from your registration”, listing the removed guests, the event, and the refund status.

You don’t need to take any action — but the resulting refunds appear on your Refunds page (in Pending if approval is required, otherwise straight through to Processing → Processed).

Edge cases

Multi-payment registrations

When a registration was paid for in two or more separate Stripe payments — for example, the registrant added guests in a later checkout — each attendee’s refund routes back to the specific payment that paid for that attendee. The mapping is tracked per attendee, so you don’t have to pick the source payment yourself.

Late-fee-only attendees

If a member registered for a $0 ticket but was charged a late fee, the attendee counts as paid. Removing them creates a refund row for the late-fee amount.

Free attendees

Attendees on a $0 ticket with no late fee never produce a refund row. They are cancelled cleanly and don’t appear on the Refunds page. This is intentional — there’s no money to send back.

Already-refunded attendees

If an attendee has already been refunded on a prior removal attempt, no second refund row is created. This protects against double-refunding when retrying or replaying actions.

Past-deadline cancellations

If the event’s refund deadline has passed, the attendee is still cancelled but no refund row is created. The notification email to the member (if sent) explains why no refund will be issued.

When a refund fails

Common Stripe failure modes you’ll see in the Failed section:

• Charge already fully refunded. The source payment has nothing left to refund — usually because someone refunded it out-of-band in the Stripe dashboard. Deny the row.
• Stripe account configuration. Your Stripe account isn’t able to process the refund right now (for example, insufficient balance for an instant refund). Resolve the issue in Stripe, then Retry.
• Network or transient errors. Retry usually works.

If you need to refund the customer manually in the Stripe dashboard, do that first, then Deny the row in Seva so it doesn’t sit in the Failed section.

Next steps

• Managing Registrations — Cancelling whole registrations and managing attendees
• Tickets & Pricing — Where ticket prices are configured
• Managing Events — Where the per-event refund deadline is configured