Case Study

Building a three-sided marketplace payment system with Stripe Connect

How we designed a payment architecture that distributed funds to three beneficiaries per transaction while retaining platform fees

BT

Key results at a glance

3
Beneficiaries
per transaction
Stripe Connect
Integration
payment platform
4+
Payment States
booking-linked

The challenge

The Business Model

Spa Space operated a three-sided marketplace where:

  • Wellness providers (therapists, practitioners) delivered services
  • Venues (spas, hotels, wellness centres) hosted the services
  • The platform connected them and handled bookings

Each booking generated revenue that needed to be distributed fairly among all three parties - a payment complexity that goes well beyond standard e-commerce.

The Payment Problem

Traditional payment systems are designed for two parties: buyer and seller. A three-sided marketplace breaks this model:

  • Multiple beneficiaries per transaction
  • Variable splits depending on service type and agreements
  • Platform fee retention before distribution
  • Booking-linked payments with deposits, balances, and refunds
  • Compliance requirements for money transmission

The Complexity

  • Each booking could involve different providers and venues with different fee structures
  • Payments needed to match booking states (deposit at booking, balance after service)
  • Cancellation and refund scenarios had to handle partial payments correctly
  • Regulatory compliance required proper fund segregation
  • The business model was still evolving, requiring flexibility in split configurations

The results

Key results

  • Three-sided payment distribution automated through Stripe Connect
  • Platform fee retention built into every transaction
  • Booking lifecycle tightly integrated with payment state
  • Compliant architecture using Stripe's regulated fund flows
  • Configurable split calculations supporting evolving business terms

Payment Distribution

  • Three beneficiaries supported per transaction
  • Platform fees retained automatically at payment time
  • Compliant fund flow through Stripe's regulated infrastructure

Operational Benefits

  • Automated settlements - no manual payment processing
  • Clear audit trail - every payment linked to a booking
  • Reduced disputes - transparent split calculations
  • Scalable model - could handle any volume without process changes

Business Flexibility

  • Configurable splits - fee structures could be adjusted per provider or venue
  • Multiple payment models - supported deposit + balance, full prepayment, and pay-on-arrival
  • Refund handling - automated proportional refunds when bookings cancelled

The solution

Our Approach

We designed a payment architecture using Stripe Connect with separate connected accounts for providers and venues, enabling compliant multi-party payments with the platform as the orchestrator.

Connected Account Structure

Rather than aggregating funds centrally (which creates regulatory complexity), we used Stripe Connect's model:

  • Platform account for overall orchestration and fee collection
  • Provider accounts (Express) for therapist payouts
  • Venue accounts (Express) for venue payouts

This structure meant funds flowed directly to recipients through Stripe's regulated infrastructure, reducing compliance burden on the platform.

Payment Flow Design

Customer Payment
       |
       v
  Stripe Checkout
       |
       v
  Platform Fee Retained (10-15%)
       |
       +--> Provider Account (service fee)
       |
       +--> Venue Account (venue fee)

The payment was split at the point of transaction using Stripe's transfer_data and application_fee_amount parameters, ensuring clean fund segregation.

Booking-Linked Settlement

Payments were tightly integrated with booking state:

  1. Booking created - Payment intent created with calculated splits
  2. Customer pays deposit - Partial capture, funds held
  3. Service completed - Final balance captured and settled
  4. Booking cancelled - Appropriate refunds issued to correct parties

Implementation Details

  • Dynamic split calculation based on service type, provider agreement, and venue terms
  • Idempotency to prevent duplicate charges on retries
  • Webhook handling for Stripe events (payment succeeded, failed, disputed)
  • Reconciliation to match Stripe transactions to booking records
  • Payout scheduling aligned with business cash flow requirements
Technical deep dive

Why Stripe Connect?

Several options exist for marketplace payments, but Stripe Connect offered key advantages:

  1. Regulatory compliance - Stripe handles money transmission licensing
  2. Connected accounts - Direct relationships with recipients, not aggregated funds
  3. Flexible payouts - Platform controls payout timing
  4. Global reach - Supports international expansion
  5. Developer experience - Well-documented APIs and testing tools

Split Calculation Service

The split calculation was implemented as a dedicated service:

SplitCalculationService
  - getProviderRate(providerId, serviceType)
  - getVenueRate(venueId)
  - getPlatformFee(bookingValue)
  - calculateSplit(booking) -> { platform, provider, venue }

This separation meant business rules for splits could evolve independently of the payment integration.

Handling Edge Cases

The implementation addressed several complex scenarios:

Partial refunds: When a booking was partially refunded (e.g., service shortened), the refund was proportionally distributed based on original splits.

Disputes: Chargebacks were handled through Stripe's dispute process, with the platform retaining evidence of service delivery.

Failed payouts: If a connected account could not receive funds (e.g., verification incomplete), funds were held and retried automatically.

Multi-currency: While initial launch was UK-only (GBP), the architecture supported adding currencies for international expansion.

Webhook Reliability

Stripe webhooks were processed through a queue to ensure:

  • At-least-once processing - failed handlers retried
  • Ordering - events processed in sequence per booking
  • Idempotency - duplicate events handled gracefully

Lessons Learned

  1. Test with Stripe's test mode extensively - edge cases in payments are expensive to discover in production
  2. Build reconciliation from day one - matching Stripe records to internal state saves debugging time
  3. Plan for disputes - have evidence collection built into the booking flow
  4. Consider payout timing - provider and venue cash flow expectations matter to business relationships

Ready to achieve similar results?

Let's discuss how we can help your organisation achieve these results.

Book a strategy call

Project Delivery & Rescue

Critical project stuck? Need senior oversight for a complex build? Get technical leadership for projects that require architectural depth, AI-augmented practices, and experienced decision-making

Learn more →

Architecture Advisory

De-risk critical architecture decisions with on-demand senior advice. Get peer-level technical depth for complex systems, AI adoption strategies, and architectural reviews, without hiring a full-time architect.

Learn more →

The service, sector and engagement this piece of work belongs to.

Service

  • Project Delivery & Rescue

    Critical project stuck? Need senior oversight for a complex build? Get technical leadership for projects that require architectural depth, AI-augmented practices, and experienced decision-making

  • Architecture Advisory

    De-risk critical architecture decisions with on-demand senior advice. Get peer-level technical depth for complex systems, AI adoption strategies, and architectural reviews, without hiring a full-time architect.

Engagement

  • Spa Space Inc

    Fractional CTO for a US wellness marketplace startup, architecting a 45+ microservice platform, managing teams of up to 20 developers across three agency engagements, and learning critical lessons about authority, title, and technical leadership in volatile business environments.

Michael Card

Delivered by

Experienced Fractional Chief Technology Officer (CTO), Architect, and .NET developer with a strong background in leading technical strategy and building scalable applications across diverse industries

More from Michael