# Fees and Payouts (/docs/live-events/fees-and-payouts)



Every event uses one of two monetization models, chosen on the event's **Pricing** tab while it is
still a draft. The model decides how Resytech gets paid, what the buyer sees at checkout, and what
you net per ticket. It is locked at publish, so pick it before the event goes live.

The Two Models [#the-two-models]

|                   | Per-ticket fee                                                      | Flat listing fee                                   |
| ----------------- | ------------------------------------------------------------------- | -------------------------------------------------- |
| **When you pay**  | On every ticket sold, taken out of the sale automatically.          | Once, up front, before the event can be published. |
| **What it costs** | A set amount per ticket.                                            | A flat amount based on the event's total capacity. |
| **Who pays it**   | You absorb it, or you pass it to the buyer.                         | You, on your own card.                             |
| **Buyer sees**    | Nothing extra when absorbed. A **Service fee** line when passed on. | Nothing extra.                                     |
| **At checkout**   | Resytech takes its cut from each order.                             | Resytech takes nothing from orders.                |

Add-ons never carry a per-ticket fee. Only ticket lines are counted.

Per-Ticket Fee [#per-ticket-fee]

The per-ticket amount is set for your organization (Resytech can agree a rate with you; otherwise
the platform default applies). The important part for operators: &#x2A;*the amount is frozen onto the
event when you publish it.** A rate change later never re-prices an event that is already selling.
Once published, the Pricing tab shows the frozen amount and whether it is absorbed or passed on.

Absorb (the default) [#absorb-the-default]

The buyer pays exactly the ticket prices plus tax. Nothing about the platform fee is visible to
them. The fee comes out of your side of the sale, and Stripe's card processing fee is yours too.

Two tickets at $30, no tax, a $1.50 per-ticket fee:

|                          | Amount         |
| ------------------------ | -------------- |
| Buyer pays               | $60.00         |
| Resytech fee (2 tickets) | $3.00          |
| Stripe processing        | roughly $2.04  |
| You net                  | roughly $54.96 |

Pass to buyer [#pass-to-buyer]

Turn on **Pass fees to buyer** on the Pricing tab (draft events, per-ticket model only) and
checkout gains a **Service fee** line. The line covers both the Resytech fee and an estimate of
Stripe's processing fee, calculated so that after Stripe takes its cut you still receive the full
ticket price plus tax.

Same two tickets at $30, no tax, with the toggle on:

|             | Amount |
| ----------- | ------ |
| Subtotal    | $60.00 |
| Service fee | $5.19  |
| Buyer pays  | $65.19 |
| You net     | $60.00 |

The processing part of that line is an estimate based on standard card rates. Premium and
international cards cost more to process, so on those orders the real Stripe fee slightly exceeds
what was collected, and the shortfall is yours. It is small, but it means "pass to buyer" gets you
close to whole rather than exactly whole.

One safeguard: the Resytech fee can never exceed the order total. On a very cheap or free ticket
in absorb mode, the fee is capped at what the order is actually worth.

Flat Listing Fee [#flat-listing-fee]

Instead of a cut of each sale, you pay a single fee before the event goes live. Nothing is taken
from orders afterwards, and the buyer never sees a service fee.

The fee is set by **capacity brackets**: the cheapest bracket whose limit covers your event's
total capacity is the one you pay. Capacity here means the sum of the capacities of all active
ticket types on the event. If a negotiated bracket set exists for your organization it replaces
the standard one entirely rather than mixing with it.

Paying it [#paying-it]

While the event is a draft, an amber banner on the event page shows the amount due and a **Pay
Listing Fee** button. The payment window shows the fee for your current capacity, anything already
paid, and the amount due now, then takes a card. If your bank asks for authentication, the window
walks through it and finishes the payment afterwards.

Notes:

* The charge goes to Resytech directly on your card, in USD. It is not taken out of ticket revenue
  and it does not touch your Stripe Connect account.
* It is charged once. Reopening the window on an event that is already covered reports "Listing
  fee covered" rather than billing again.
* If the event has no ticket capacity yet, or no bracket covers the capacity, the window says so
  instead of taking a card. Add capacity first, or contact support.
* Cancelling an event does not automatically refund a listing fee.

Capacity increases and top-ups [#capacity-increases-and-top-ups]

The publish check compares what you paid against the bracket for your capacity **right now**. If
you raise capacity after paying and cross into a more expensive bracket, publishing is blocked
until you pay the difference. The payment window handles this for you: it shows the full fee for
the new capacity, credits everything already paid, and charges only the outstanding amount. This
also applies to an event that was published, cancelled, and rebuilt with more seats.

Tax [#tax]

Tax is a single per-event rate, entered as a percentage on the **Pricing** tab. It is applied to
the order subtotal (tickets and add-ons) and added on top of it, and appears to the buyer as a
**Tax** line at checkout and on their confirmation. Leave it blank for no tax.

The rate stays editable after publishing, but it only affects orders placed from that point on.
Orders already paid keep the tax they were charged.

Payouts and Stripe Connect [#payouts-and-stripe-connect]

Ticket money never sits with Resytech. Each order is charged directly on your organization's
connected Stripe account, with the Resytech fee taken as a fee on that charge, so payouts follow
your normal Stripe payout schedule and settle to your own bank account. Stripe's processing fee is
charged to you as the merchant, which is why the "pass to buyer" option exists.

Because of that, &#x2A;*charges must be enabled on your Stripe account before an event can go live.**
Resytech tracks this from Stripe and keeps it up to date automatically as your onboarding
progresses.

* If charges are not enabled, publishing fails with a banner linking to payout setup.
* If they are somehow switched off later, the public page still loads but the ticket list is
  replaced with a note that sales are not open yet, and checkout is refused.

Finish Stripe onboarding once and it applies to every event your organization runs.

The event's sales summary reports gross revenue, refunds, net revenue, and the total platform fees
taken, broken down by ticket type and add-on. See
[Sales and Attendees](/docs/live-events/sales-and-attendees).

Related [#related]

* [Publishing](/docs/live-events/publishing)
* [Ticket Types and Add-Ons](/docs/live-events/tickets-and-add-ons)
* [Orders and Refunds](/docs/live-events/orders-and-refunds)
* [Sales and Attendees](/docs/live-events/sales-and-attendees)
* [The Storefront](/docs/live-events/storefront)
