Inside a Stripe Connect Payment Model Built for Clubs, Not Platforms

A question we get early in almost every conversation with a club director: does the platform touch our money? It's the right question to ask, and the honest answer shapes a lot of how we built the payment layer — the club is the merchant of record, always. The platform routes and tracks transactions. It never custodies funds.

Why merchant-of-record matters more than it sounds

A lot of youth sports software quietly makes the platform itself the merchant of record — money flows into the platform's account, and the club effectively gets paid out by the vendor, on the vendor's schedule, under the vendor's terms. That's a meaningfully different relationship than it first appears. It means a club's revenue is sitting inside someone else's account until a payout happens, subject to that vendor's payout timing, dispute handling, and — in a worst case — that vendor's solvency.

We built on Stripe Connect specifically because it supports the opposite model: each club has its own connected account, funds from families flow directly into that account, and the platform never sits in the custody path. The club can see its own Stripe dashboard, reconcile its own transactions, and isn't waiting on anyone else's payout cycle to access money families already paid.

What this looks like architecturally

Every club on the platform gets its own Stripe Connect account, onboarded through Stripe's standard KYC flow — not a shared platform-level account with clubs as sub-ledger entries. When a family pays a registration fee or a payment plan installment, the charge routes to that specific club's connected account directly. The platform's role is orchestration: triggering the charge at the right moment, tracking its status against the athlete record, handling refunds and plan logic — never holding the money in between.

This has a real technical cost. A shared platform-level account is simpler to build against — one Stripe account, one set of API credentials, most of Stripe's built-in tooling working with minimal extra logic. Connect accounts mean managing onboarding status per club, handling the cases where a club's account isn't yet fully verified, and building refund and payment-plan logic that respects each club's individual account boundaries rather than one unified ledger. We took on that complexity because the alternative — simpler for us, worse for clubs — wasn't a tradeoff worth making.

What it means for refunds and plans

Because each club owns its connected account, a refund is a refund inside that club's own Stripe relationship — not a request routed through a third party who has to release funds back. Payment plans work the same way: each installment is a direct charge to the club's account, tracked against the athlete record for status, but never passing through platform-level custody at any point in the cycle.

This also means a club's financial relationship with its own families doesn't depend on the platform staying in business. If a club ever needed to leave the platform, their Stripe account — and their transaction history — is theirs, not something they'd need to extract from a vendor's shared ledger.

The actual answer to "does the platform touch our money"

No. The platform sees transaction status and metadata — enough to keep an athlete's record accurate — but the money itself moves directly between family and club, through infrastructure the club can independently verify at any time. That's not a marketing claim; it's the specific reason Connect was the only architecture we considered building on.

---

TravelSportsHQ routes every transaction through Stripe Connect with the club as merchant of record — the platform tracks status, but funds never pass through platform custody.