Stripe Connect for Booking Marketplaces: Payments, Payouts, Refunds and Compliance

The Moment a Booking Platform Becomes a Payments Problem

Taking a card payment is a solved problem. Any developer can integrate Stripe Checkout in a morning and have money arriving in a bank account by lunchtime.

Taking a card payment, keeping a commission, paying the rest to a third party, handling a partial refund six weeks later, splitting a cancellation fee between two parties, producing an invoice each of them accepts, and doing all of it without becoming a regulated money transmitter — that is a different problem entirely, and it is the one every marketplace and multi-operator booking platform eventually hits.

This is a practical guide to that problem, built around Stripe Connect because it is what most UK and EU marketplaces end up using. The principles apply regardless of provider; the specifics assume Connect.

Never Route Money Through Your Own Account

The single most important architectural decision, and the one that is hardest to undo, is that you should not collect the full booking value into your own bank account and then pay operators out of it.

That model — money in, money out — is straightforward to build and it makes you, in substance, a payment intermediary. In the UK and EU that risks bringing you within the scope of payment services regulation, with authorisation requirements, safeguarding obligations, and capital rules attached. There are exemptions, notably the commercial agent exemption, but relying on one is a legal decision you should be taking with advice, not a default your developer picks because it was easier.

Stripe Connect exists specifically so you do not have to. Each operator on your platform gets their own connected Stripe account. The customer's payment is attributed to that operator's account, your commission is taken as an application fee, and the funds settle to the operator directly. You never hold their money.

Build it this way from day one. Migrating a live marketplace from a pooled account to Connect means re-onboarding every operator, reconciling in-flight bookings across two models, and explaining to your partners why they need to complete identity verification again. It is one of the least enjoyable migrations there is.

Choosing a Connected Account Type

Connect offers several account types, and the choice determines who handles onboarding, who owns the relationship with Stripe, and who is liable for disputes.

• Standard accounts. The operator has a full Stripe account with their own dashboard and login. They handle their own onboarding, and Stripe's relationship is with them. Lowest liability for you, least control over the experience. Good when your operators are established businesses who probably already have Stripe.
• Express accounts. Stripe provides a hosted onboarding flow and a limited dashboard. You get a reasonably branded experience without building identity verification yourself. This is the sensible default for most marketplaces and the one we reach for most often.
• Custom accounts. You build the entire onboarding and dashboard experience yourself and take on substantially more compliance responsibility. Choose this only when the operator experience is genuinely core to your product and you have the appetite for the obligations.

For a booking platform onboarding independent operators — car parks, restaurants, activity providers, clinics — Express hits the right balance almost every time. The operator completes a Stripe-hosted flow, submits their identity and bank details, and you get a webhook when they are ready to accept payments.

Direct, Destination, or Separate Charges

Once accounts exist, you choose how each payment is structured. This decision has consequences far beyond code.

• Direct charges. The payment is created on the operator's account. The operator appears on the customer's card statement, the operator pays the Stripe fees, and critically the operator bears the chargeback liability. Your commission comes through the application fee.
• Destination charges. The payment is created on your platform account and immediately transferred to the operator. Your name appears on the statement, you pay the Stripe fees, and you bear chargeback liability.
• Separate charges and transfers. You take the payment and transfer funds later, independently. Maximum flexibility, maximum bookkeeping.

The determining question is whose brand the customer believes they are buying from. If a customer books "Heathrow Meet and Greet" through your comparison platform and sees an unfamiliar operator name on their statement, you will get chargebacks purely from confusion. If your brand is on the statement, you own the dispute.

For platforms where the operator is clearly the merchant, direct charges are cleaner and safer. For platforms where you are the customer-facing brand, destination charges are the honest structure — and you should price the chargeback risk into your commission accordingly.

Separate charges and transfers earn their complexity in one specific case: when a single customer payment covers services from more than one operator, or when the split cannot be determined at the moment of payment.

Deposits, Balances and Delayed Capture

Booking businesses rarely take a single full payment at a single moment, and this is where naive integrations fall down.

Patterns worth building for explicitly:

• Deposit now, balance later. Two payment records against one booking, with the balance charged automatically at a defined point or collected on arrival. Do not model this as a single payment with a "partially paid" flag; you will regret it during the first refund.
• Authorise now, capture later. Useful when a booking needs confirming by the operator before money moves. Be aware that card authorisations expire — typically within seven days — so a capture window longer than that needs a saved payment method and a fresh charge instead.
• Save the card, charge on completion. Common for services where the final amount is not known upfront. Requires storing a payment method with the right off-session consent captured at the time.

Whatever the pattern, store the provider's payment intent identifier against your booking and treat your own records as a mirror of the provider's state rather than the source of truth. When they disagree, the provider is right.

Refunds, Cancellations and Who Absorbs What

Refund logic is where marketplaces discover that their commercial agreements were never fully specified.

A customer cancels a £120 booking within the free-cancellation window. You refund £120. But you already took £18 in commission and the operator already had £102 attributed to them. Three questions immediately arise: does your commission get refunded too, does the operator's balance have enough in it to fund the refund, and who absorbs the payment processing fee, which the card networks do not return?

These questions need commercial answers before they need code:

• Full refunds within the free window usually reverse the application fee as well. Keeping commission on a booking that generated no revenue for the operator poisons partner relationships quickly.
• Partial refunds and cancellation fees need an explicit split rule. If the customer forfeits £30 on a late cancellation, does the operator keep all of it, or is it split at the usual commission rate?
• Processing fees are not recoverable on refunds. Somebody absorbs them, and your agreement should say who.
• An operator with insufficient balance produces a negative balance situation. Stripe handles the mechanics, but your platform needs to detect it, surface it, and have a policy.

Build the refund path with the same care as the payment path. In every booking marketplace we have worked on, refunds and amendments generate more support load and more partner friction than the original transactions.

Payouts and the Reconciliation Question

With Connect, payouts to operator bank accounts are largely handled for you on a schedule you configure. The part that is not handled for you is explaining the numbers.

Every operator will, sooner or later, ask why last week's payout was £3,847.22 and not the £4,120 they calculated. The answer is usually some combination of refunds, chargebacks, commission, processing fees, adjustments, and a booking that settled on a different day. If your platform cannot produce a statement that reconciles line by line to that figure, you will spend hours on the phone every month.

Build the statement early:

• Every booking as a line, with gross value, commission, fees, and net.
• Refunds and adjustments as their own lines, referencing the original booking.
• A running balance and the payouts that drew it down.
• Downloadable as CSV, because operators will want to reconcile against their own accounting.

This is unglamorous work and it is the feature that most improves partner satisfaction on a marketplace.

Disputes and Chargebacks

Whoever bears chargeback liability under your charge structure needs evidence, and the platform is usually the only party that has it.

What to retain against every booking, automatically:

• The full booking record with timestamps.
• The terms and cancellation policy as they were shown at the time of booking, not as they are today.
• Confirmation emails sent, with delivery status.
• Any amendment history.
• Proof of service where it exists — entry and exit records, delivery photographs, check-in timestamps.

A dispute response assembled from these wins far more often than one assembled from memory three weeks later. Build the evidence pack as a feature rather than a manual scramble.

VAT and Invoicing

The tax treatment of a marketplace transaction depends on whether you are acting as agent or principal, and the two produce quite different invoicing obligations.

Acting as an agent, the operator supplies the service to the customer and you supply a commission service to the operator. Two documents exist: the operator's invoice to the customer, and your commission invoice to the operator, with VAT on the commission.

Acting as principal, you buy from the operator and sell to the customer, and you invoice the customer for the full amount. This changes your VAT position materially and, in the UK, can accelerate you toward the registration threshold much faster than the agent model.

This is a genuine tax question, not a software one, and it should be settled with an accountant before the invoicing logic is written. Retrofitting a change of model across historical transactions is painful and sometimes not fully possible.

Multiple Currencies and Cross-Border Operators

The moment a platform lists operators in more than one country, currency becomes a design decision rather than a display format.

The questions to settle explicitly: what currency does the customer pay in, what currency does the operator get paid in, and who bears the conversion cost and the exchange rate risk between the booking and the payout.

The clean answer for most marketplaces is that the customer pays in the currency of the service's location, the operator is paid in their own currency, and no conversion happens at all. Where the platform wants to present prices in the customer's currency, treat that as a display conversion with a clearly marked indicative rate, and charge in the underlying currency — or accept that you are taking the conversion risk and price it in.

On the technical side, store every monetary amount as an integer in the smallest unit alongside its currency code, never as a floating point number and never as a bare number whose currency is implied by context. Commission, refunds, and reporting all need the currency travelling with the amount, and platforms that added a second currency later almost always find that assumption baked into a dozen places.

Testing Payments Properly

Payment code is the code most likely to be under-tested and most expensive when wrong. What we insist on:

• Use test mode connected accounts and exercise the full lifecycle, including onboarding, payment, partial refund, full refund, dispute, and payout.
• Make every webhook handler idempotent. Providers retry, and duplicate delivery is normal rather than exceptional. A handler that creates a second booking or a second refund on retry is a real financial bug.
• Verify webhook signatures. An unverified endpoint that mutates booking state is a vulnerability, not just a bug.
• Never trust the client-side success callback. Confirm state from the webhook or a server-side retrieval before treating a booking as paid.
• Test the failure paths deliberately — declined cards, expired authorisations, disabled connected accounts, and insufficient balance refunds. These will all happen in production.

The Short Version

Use Connect rather than pooling money. Choose Express accounts unless you have a specific reason not to. Pick your charge type based on whose brand the customer thinks they are buying from, and accept the chargeback liability that follows. Specify refund splits commercially before you build them. Produce a reconcilable operator statement from day one. Settle the VAT model with an accountant before writing invoicing code.

We have built payment and payout flows for booking platforms and marketplaces including BookFlow Pro and several airport parking operators, and the recurring lesson is that the commercial decisions are harder than the integration. If you are designing a marketplace payment model and want to pressure-test it before it goes live, our contact page is a good place to begin.