Fresha's payments documentation describes a wallet, not a set of connected accounts. If you're choosing a Stripe Connect charge type for a booking platform, spend ten minutes on the five-question test further down before you write any integration code, because the topology is the one payments decision you can't refactor cheaply once real merchants are on it.
The assumption most people start from is that a clinic or salon is an independent business, so each one must be its own merchant. Fresha's payments overview says "All payments are securely collected into your business wallet", and describes automatic sales splits that route funds to the right team member's account. Money pools at the platform first and leaves later.
I made the opposite call on a clinic SaaS. It was a decision with trade-offs, not an obvious answer, and the rest of this post is the reasoning.
Stripe Connect direct charges or destination charges: whose balance holds the money?
With direct charges the payment lands in the connected account's balance, while with destination charges it lands in your platform's balance, and refunds, chargebacks and processing fees follow that money.
Stripe's Connect charges documentation says the charge type "determines whether your platform's or the connected account's information appears on the customer's bank or billing statement and which account Stripe debits for refunds and chargebacks." Everything below is a consequence of that one choice, and it is a legal decision as much as a technical one.
| Direct charges | Destination charges | Separate charges and transfers | |
|---|---|---|---|
| Payment lands in | Connected account's balance | Platform's balance | Platform's balance |
| Refunds and chargebacks reduce | Connected account's balance | Platform's balance | Platform's balance |
| Stripe fees | Platform or connected account, your choice | Platform | Platform |
| Recommended negative-balance liability | Stripe | Platform | Platform |
| Stripe's example use case | A SaaS platform, such as an accounting product that enables invoice payments | A branded service using independent contractors, such as a rideshare app | An e-commerce marketplace with one cart covering several sellers |
Stripe is describing three different kinds of company, not three code paths. A rideshare app owns the customer relationship and the driver is interchangeable. An accounting platform doesn't own the invoice, so the accountant's client is paying the accountant. If you can't say in one sentence which of those your business resembles, you aren't ready to pick.
One detail catches cross-border platforms: for direct charges, Stripe states that funds always settle in the country of the connected account. That is either what you want or a tax question you find late.
What does a pooled wallet like Fresha's imply?
Fresha's pricing page (checked 30 September 2026) lists online payments at 2.79% + $0.20 per transaction, in-person at 2.29% + $0.20 and manual card entry at 3.30% + $0.20. Subscriptions cost $19.95 a month for an independent or $14.95 per team member, and new clients found through the Fresha marketplace carry a 20% one-time commission with a $6 minimum. Returning clients are free.
That commission is my reason for reading the wallet as a business-model choice. This suggests that billing a percentage of a booking the platform originated is easier when the platform sits in the flow of funds at the moment the money moves. Fresha doesn't publish its Stripe-level topology, so treat that as inference from public documents, not a description of its internals.
For comparison, Stripe's Connect pricing page (checked 30 September 2026) lists $2 per monthly active account and 0.25% + 25¢ per payout when you handle pricing, with standard card processing at 2.9% + 30¢. Those are list prices for one configuration, and Stripe says fee behaviour changes with who collects fees, so model your own numbers before comparing.
Which topology should a booking platform pick?
Pick direct charges when each business is the legal seller of the service, and destination charges when the customer is buying your own platform's brand. Here is the sequence I'd work through before writing Connect code:
- Name the merchant of record for the underlying service, meaning the treatment or appointment rather than the software that scheduled it. Whose licence, insurance and registration are on the line if something goes wrong? That party should hold the money.
- Ask who the customer thinks they are paying. Check the booking confirmation, the statement descriptor and the refund email. If the answer is "the clinic", direct charges keep the story consistent.
- Decide whether one payment must split across several parties. Stripe positions separate charges and transfers for the one-to-many case, at the price of a more complex integration.
- Check whether your commercial model takes a cut of bookings you introduced. An acquisition fee like Fresha's is easier to bill when funds pass through you.
- Decide whether you can live with the dispute posture. Under direct charges Stripe debits the disputed amount from the connected account's balance, which suits a merchant who is genuinely liable and confuses one who thinks you're their bank.
Run them in order. Starting from "which is easier to build" reverses the logic, because build effort is a consequence of the answer and not an input.
Consider a hypothetical clinic that has just taken its first deposits and issues a refund before any payout has landed. Under direct charges, Stripe's documentation says the refund is debited from the connected account's balance, and if that balance is insufficient the refund status is set to pending until funds arrive. That is a support conversation your booking platform's help pages should answer before the first cancellation, not after it. Under destination charges the same refund reduces your platform balance instead, so the cost of a cancellation lands on you.
Are direct charges a liability firewall?
No. Stripe's fee-behaviour documentation says that for direct charges Stripe always attempts to debit a disputed amount from the connected account first, and that where it can't, ultimate responsibility depends on who is responsible for negative balances. Dispute fees follow the fee-collector setting separately: the platform pays them when it is set to application, and the connected account pays them otherwise. Stripe's integration recommendations suggest assigning negative-balance liability to Stripe for direct charges, which is a setting worth checking rather than assuming.
What I shipped on Callidus
I built Callidus OS, a multi-tenant clinic SaaS for UK aesthetic clinics, on Stripe Connect Standard with direct charges, one Connect account per clinic and a 0.1% application fee on patient deposits collected through the booking widget. The reasoning was step one of the list. Each clinic is the legal merchant of record for the medical services it performs, so pooling deposits in the platform's account would have moved liability in the wrong direction. The stack is React, Firebase and Stripe Connect, and the tenant model behind it is described in what multi-tenant SaaS means for data isolation.
Twenty webhook events are handled across the subscription lifecycle. One of them is invoice.payment_action_required, which Stripe documents as sent when an invoice requires customer authentication. In Callidus it triggers 3D Secure escalation and emails the owner a hosted invoice URL. Two more details from the same billing surface: annual pricing blocks promo codes through an explicit ANNUAL_PRICE_IDS allowlist to prevent 100%-off abuse, and routing Connect webhooks by tenant works because, per Stripe's Connect webhooks documentation, each event for a connected account carries a top-level account property identifying it.
If you're sizing a similar build, the payment integration is only part of the cost; the role matrix and tenant isolation are the rest. The app cost estimator gives a rough number, and my notes on Stripe subscription billing for SaaS cover the recurring side.
Did Stripe deprecate the account types this pattern uses?
Stripe's integration recommendations page labels the legacy account types (Standard, Express and Custom) as "(deprecated)" and recommends the Accounts v2 API for new integrations, with a migration path for existing platforms.
The charge-type semantics in the table above haven't changed. What changes is the object that holds them and its vocabulary: controller.fees.payer on v1 corresponds to defaults.responsibilities.fees_collector on v2, per the fee-behaviour page. That page also says "You can specify the fee payer only when you create an account." My inference, not Stripe's statement, is that a pricing change later may mean onboarding merchants again, so decide the fee payer before your first connected account exists. Callidus was built on Standard, and I haven't assessed a migration.
Before you open the Connect dashboard, find the indemnity clause in your merchant terms, open docs.stripe.com/connect/charges beside it, and check that both documents agree on who is liable when a customer disputes a charge. If they disagree, which one is your payment topology implementing?