> ## Documentation Index > Fetch the complete documentation index at: https://docs.orriven.com/llms.txt > Use this file to discover all available pages before exploring further. # Payments > Connect each Business Unit's Stripe account, read its status, and understand prices, currency, the platform fee, and refunds. Free events do not need any of this. orriven uses **Stripe** to take payments. A buyer pays on Stripe's hosted payment page. Payouts settle to the Business Unit's connected Stripe account. **Payments** in the organization section of the console gathers every Business Unit's Stripe connection on one page — one card per unit. A free event needs none of this. A 0-amount order settles at confirmation without a payment provider, so registration, ticketing, agenda, housing, and email all work with no Stripe account. Only **paid** orders need a connected account. ## Connect a Business Unit to Stripe In the organization section, open **Payments**. Every Business Unit the current member can open has a card. A unit with no account yet reads "Connect a Stripe account to sell paid tickets." The browser opens Stripe's onboarding — business details, bank account, identity verification. When Stripe is done, it returns to this page. Onboarding left partway shows as **Onboarding incomplete** with a **Resume onboarding** button. Once Stripe has enabled charges, the card shows **Ready to take payments**. Organization Owners and Admins can always connect. Other roles need the *Update* permission on **Business unit settings** — see [Roles](/en/organization/roles). A unit whose settings the current member cannot open shows no card. ## Reading a unit's card | Shown | Meaning | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | **Ready to take payments** | Stripe has enabled charges. Paid orders on this unit's events can be placed. | | **Onboarding incomplete** | Stripe still needs something. Choose **Resume onboarding**. Paid orders stay unavailable until this clears. | | **Inherited from organization** | This unit has no account of its own and uses the organization's default account. Its onboarding buttons are not offered here. | | **Country** / **Default currency** | What Stripe recorded for the account. | | **Payouts** — *Enabled* / *Not yet* | Whether Stripe pays out to the bank account yet. | | **Open Stripe Express dashboard** | Payouts, balances, and statements live on Stripe's side. Opens in a new tab once the account details have been submitted. | If the whole page reads **Payments are not enabled on this platform**, there is nothing to connect: the platform is running without a payment provider, and every event is free. Stripe issues the invoice and receipt for every paid order. An order-confirmation [automation](/en/marketing/automations) should not send a second receipt. ## What buyers experience * **Connected and ready** — a paid order on the hosted checkout is confirmed, the buyer is sent to Stripe, and returns to the hosted order page when the payment succeeds. Settlement creates the registration and sends the ticket email, the same as for a free order. * **Not connected, or onboarding incomplete** — a paid order cannot be placed. The buyer is told that paid orders are not available for this event yet. Free tickets on the same event keep working. Finishing onboarding fixes it. Nothing on the event has to change. See [Orders](/en/ticketing/orders) for the order lifecycle, including the longer hold a paid order keeps while the buyer is on Stripe. ## Prices, currency and the platform fee * **Prices are set per sellable** — on each ticket type, add-on, and bundle — in the event's currency, **tax included**. 0 or empty means free. * **The currency is an event setting.** Every price on the event is stated in it, and it **locks once the event takes its first order**. Sold amounts cannot be restated in another currency. Decide it before opening sales. See [Event settings](/en/events/settings). * **Orders snapshot prices.** Changing a price later changes what the next buyer pays, never an existing order. * **A platform fee** — a percentage of each paid order — is deducted before payout and shown on the order's detail page under **Payment → Platform fee**. Stripe's own processing fees are settled on Stripe's side. * A redemption code carrying a 100 % discount produces a free order that never touches Stripe. See [Offers & redemptions](/en/ticketing/offers). ## Refunds Refunds are issued from an order's detail page (**Orders → View**), in the **Refunds** section. They require the **Finance → Refund** permission — Owners and Admins only. Planners and on-site staff cannot move money. Only a **Completed** order with a settled payment can be refunded. The page shows the total, any discount, **Refunded so far**, and how much remains refundable. If what was bought cites a [refund policy](/en/ticketing/refund-policies), the page states the suggested amount for the current window and pre-fills it. The amount can be changed. Any amount up to what remains is accepted. A reason is optional. The refund appears in the list as **Pending**, then **Succeeded** or **Failed** once Stripe confirms. **Refunded so far** updates with it. What a refund does: | | Registration | Platform fee | | -------------------------- | --------------------------------------------- | ------------ | | **Full refund, in one go** | Cancelled — the seat goes back with the money | Returned | | **Partial refund** | Kept | Kept | A refund that eventually empties the order — several partials adding up to the total — also cancels the registration, but the platform fee is only returned on a single full refund. An order refunded in full shows the status **Refunded**. ## Rules to know * **Free events never touch Stripe.** Zero setup, zero fee, and the flow is identical with or without a connected account. * **Payments are connected per Business Unit**, because that is where the money goes. A unit using the organization's default account shows *Inherited from organization*. * **The event's currency is locked by its first order.** Price fields refuse a value that is not valid for that currency. * **The refund schedule is a suggestion.** The policy is the published promise. The organizer decides the amount. Nothing enforces it automatically. * **Refunds are a console decision.** The developer API reads orders and their status but never issues a refund. * **Connecting, onboarding, and every refund are recorded** in the [audit log](/en/organization/audit-logs). ## Related The lifecycle of every purchase, free or paid. The published schedule the refund form suggests from. Where a price is set, in the event's currency. The event's currency, locked by its first order.