Payment processor lock-in: the hidden cost

If you've ever cancelled a studio software platform and switched to a new one, you've experienced payment processor lock-in even if you didn't have the language for it. The migration plan covers the client list, the class catalogue, the active memberships, the transaction history. The plan rarely covers the payment-processing relationship, because in most studio software platforms there isn't a clean handoff: the processing relationship was the platform's, not yours, and it doesn't transfer. This post is about what that lock-in actually costs, why it persists, and what the structural alternative looks like.

The short version is in the Short answer callout at the top of this page. The long version, with the worked numbers and the architectural distinction, is below.

The two architectures, in detail

Studio software platforms route payments through one of two architectures. The distinction is invisible to the client paying for a class and is rarely surfaced clearly in the platform's marketing pages, but it matters operationally.

Bundled processing means the platform is the Stripe customer and the studio is a sub-account or merchant-of-record arrangement on top of the platform's primary Stripe relationship. The platform negotiates rates with Stripe, the platform manages the dispute flow, the platform issues payouts to the studio on its own schedule (typically weekly or bi-weekly), and the Stripe identifier on the cardholder's statement shows the platform's name rather than the studio's. From Stripe's perspective, there is one customer (the platform) and many merchants (the studios) under that customer. The platform handles the operational complexity in exchange for being the relationship owner.

Stripe Connect Standard means the studio has its own direct Stripe account, connected to the platform via OAuth during onboarding. The platform can create charges, handle refunds, and manage subscriptions on the studio's behalf, but the funds settle directly from Stripe to the studio's bank account on Stripe's standard payout schedule. The Stripe customer is the studio. The dispute flow is direct between the studio and Stripe. The cardholder's statement shows the studio's name. The platform is an authorised application that operates on the studio's Stripe account, not the relationship owner.

The two architectures are operationally close to identical from the client's perspective: the client enters their card, the booking confirms, the receipt arrives. The differences show up only at the edges — when the studio cancels the platform, when there's a dispute, when the studio applies for a small-business loan that pulls payment processing history, when the studio wants to add a new payment method.

What the bundled rate actually costs

The visible cost of bundled processing is the rate premium over Stripe's published rates. Stripe's UK published rates as of writing are 1.5% + 20p for standard UK cards, 2.5% + 20p for European Economic Area cards, 3.25% + 20p for non-EEA international cards, and 1% per transaction with a £4 cap on Bacs Direct Debit. The bundled-processing rate at most studio software platforms is typically a few tenths of a percent higher than the equivalent published Stripe rate for the same card type.

The bundled-rate cost is real but small on most studios. A few tenths of a percent on a hundred-and-fifty-thousand-pound annual card volume is roughly four hundred to nine hundred pounds a year. Worth caring about, but not load-bearing for most studio software decisions.

The Bacs Direct Debit case is different. Bacs is one percent capped at four pounds per transaction at Stripe's published rate, which means high-value Direct Debit transactions (membership payments at one hundred pounds or more) cost a maximum of four pounds in processing each. Bundled platforms typically charge a higher percentage with a higher or no cap, which means the bundled rate on a one-hundred-pound Direct Debit can be three to five pounds instead of one pound. For a studio with sixty active members on Direct Debit at one hundred pounds a month, the difference is forty to eighty pounds a month — roughly five hundred to one thousand pounds a year. For studios with meaningful Direct Debit volume, the rate dimension alone is worth caring about.

What the lock-in actually costs

The relationship-loss dimension is the bigger cost, and it's the part that's usually invisible until the moment you cancel.

When you cancel a bundled-processing platform, the historical Stripe data is the platform's data, not yours. Specifically:

Transaction history. Every charge, refund, and dispute that happened through the platform is recorded against the platform's Stripe customer, not yours. The data is exportable from the platform's reporting layer (sometimes for a fee, as in the four-hundred-pound complete-record export Mindbody is reported to charge), but it doesn't move to your new platform's Stripe relationship. Your new Stripe account starts at zero history.

Dispute history. Stripe's risk algorithms use dispute history to calculate the merchant's risk score, which affects pricing and account standing. A studio with five years of low-dispute history under a bundled-processing platform doesn't inherit that history when it starts a direct Stripe relationship. The new account is a fresh merchant from Stripe's perspective.

Payout schedule and limits. New Stripe accounts often have an initial payout delay (typically seven days for the first payout, then standardising to two-business-day rolling) and may have rolling reserve requirements while the account establishes pattern. A studio that's been running for five years on bundled processing starts the direct Stripe relationship with the same constraints as a brand-new merchant.

Merchant identifier and lender visibility. Lenders and payment partners that integrate with Stripe (Stripe Capital, third-party financing providers, accounting integrations) reference the merchant identifier. When you switch from bundled processing to direct, the merchant identifier changes, and the lender history doesn't follow you. For studios that have built up Stripe Capital eligibility under bundled processing, the eligibility resets.

Negotiated rates. Bundled platforms typically negotiate rates with Stripe based on portfolio volume, which means the rate you pay through bundled processing may be tied to the platform's volume rather than your own. When you switch to direct, you pay Stripe's standard pricing for your volume, which may be higher or lower depending on your individual transaction profile.

The cumulative effect of these dimensions is that the lock-in cost is meaningfully higher than the rate-premium cost. A studio that's been on a bundled-processing platform for three years and switches to direct Stripe Connect Standard typically loses six to twelve months of effective Stripe relationship maturity, plus the operational overhead of re-establishing the dispute history, payout pattern, and lender visibility.

Why bundled processing exists on the vendor side

The vendor side of the bundled-processing question is worth understanding because it explains why the pattern is sticky.

For the platform, bundled processing produces three operational benefits.

Revenue stream. The rate premium over Stripe's published rates is a meaningful second revenue stream beyond subscription. Mindbody, Momence, Mariana Tek, and most of the PE-backed half of the market generate non-trivial revenue from the processing markup. For a platform doing one billion dollars in annual processed volume across its studios, even a 0.3% markup is three million dollars a year in incremental revenue. The processing markup is part of why the PE acquisition multiples in the category work the way they do.

Operational simplification on the customer side. For solo operators and very small studios that don't want to deal with Stripe directly, bundled processing is operationally simpler. The studio doesn't need to set up its own Stripe account, handle KYC, manage disputes, or learn the Stripe dashboard. The platform handles all of that in exchange for being the relationship owner.

Customer-retention lever. The relationship-loss dimension is, from the platform's perspective, a retention lever. A studio that's invested three years into a bundled-processing relationship faces a meaningful switching cost when considering a new platform, and the switching cost reduces churn. The platform doesn't articulate this publicly, but the pattern is consistent across the category: platforms that have bundled processing as the default architecture report meaningfully lower churn rates than platforms that route through direct Stripe Connect Standard.

The structural alternative — Stripe Connect Standard direct — gives up the rate-premium revenue stream and the retention lever in exchange for an aligned-incentives relationship with the studio. Operator-friendly platforms make this trade because the alignment is part of their structural positioning, and the customer-acquisition advantage of "your own Stripe account" outweighs the revenue and retention loss from the bundled-processing architecture. PE-backed platforms generally don't make this trade because the second revenue stream and the retention lever are operationally important to their valuation multiples.

How to tell which architecture you're on

Three operational signals let you determine which architecture your current platform uses without asking support.

The cardholder statement descriptor. Check a recent client's card statement (or your own card statement if you've ever paid for a class on your own platform). The descriptor is what Stripe sends to the cardholder's bank as the merchant name. If the descriptor is your studio's name, you're probably on a direct architecture (Connect Standard or similar). If the descriptor is the platform's name, the processing is bundled. Some platforms use a hybrid descriptor (studio name followed by platform name), which usually indicates bundled processing with a customisation.

The dispute flow. When a client disputes a charge, who handles the dispute? On bundled processing, the dispute notification comes to the platform's support team, which then communicates with the studio. On Connect Standard, the dispute notification comes directly to the studio via Stripe's dispute dashboard, and the studio responds directly. The dispute-flow ownership is a clear signal of the architecture.

The Stripe dashboard. Do you have direct access to a Stripe dashboard with your studio's name on it? If yes, you're probably on Connect Standard. If you only have access to a reporting layer inside the platform's own dashboard, the processing is bundled.

If you're on bundled processing, the rate-premium cost is visible (look at your monthly statement and compare the effective rate to Stripe's published rates for your card mix) but the lock-in cost is invisible until you try to leave.

The Stripe Connect Standard alternative

The structural alternative is Stripe Connect Standard direct to your own Stripe account, which is what Junocal uses.

The operational pattern: during onboarding, you connect your existing Stripe account to Junocal via OAuth (if you don't have a Stripe account, you create one, which takes about ten minutes). Junocal can create charges, process refunds, and manage subscriptions on your account's behalf via the Stripe Connect API. The funds settle directly from Stripe to your bank account on Stripe's standard payout schedule. The Stripe customer is your studio. The dispute flow is direct. The cardholder statement descriptor is your studio's name. Your Stripe history, dispute record, payout pattern, and lender visibility accumulate against your account, not Junocal's.

The trade-off is real but small. You manage your own Stripe account, which means you handle the initial KYC, you receive disputes directly (and respond to them directly), and you have the Stripe dashboard as a second operational surface alongside the Junocal dashboard. For most studios, the dual-dashboard pattern is operationally manageable: the Junocal dashboard handles day-to-day class operations, and the Stripe dashboard handles the payment-specific edge cases (disputes, payouts, refund-after-cancel scenarios).

For solo instructors who don't want to deal with Stripe directly, the operational overhead may be meaningful. For studios with even a small operations function, the overhead is small and the upside of the direct relationship is large.

What this looks like at migration time

The single most consequential moment for payment-processing architecture is the migration from one platform to another. The architecture you're on determines what happens to the payment-processing relationship when you migrate.

Migrating off bundled processing onto Stripe Connect Standard direct. The pattern: you create or activate a Stripe account during the new-platform onboarding (about ten minutes if you don't already have one). The new platform connects to your Stripe account via OAuth. From the cutover date, all new charges flow through your Stripe account directly. The old platform's bundled-processing relationship continues to handle the residual charges on cancellations or refunds for prior bookings until those bookings cycle out. Your Stripe history starts at the cutover date; the prior history sits with the old platform's Stripe customer and is exportable from the old platform's reporting layer but doesn't move.

Migrating between two direct-Stripe platforms. The pattern: you disconnect the old platform from your Stripe account, connect the new platform via OAuth. Same Stripe account, same Stripe customer, same history. The migration is operationally cleaner because the payment-processing relationship is preserved. This is the migration pattern that operator-friendly platforms support naturally.

Migrating from bundled processing back to bundled processing. The pattern: the new platform creates its own bundled-processing relationship for your studio. Your Stripe history under the old platform is lost; your Stripe history under the new platform starts at the cutover. Both platforms own the relationship, not you. This is the migration pattern that PE-backed platforms typically support, because the bundled-processing architecture is the default on both sides.

For studios that want to preserve the option of clean migrations in the future, Stripe Connect Standard direct is the structural commitment that makes the option real. The architecture you pick today determines the migration cost in five years' time.

Closing pattern

Payment processor lock-in is the largest hidden cost in the studio software category. The rate-premium cost is visible and real but small. The relationship-loss cost is invisible until you migrate, at which point it's typically the largest single cost of the migration.

The structural alternative — Stripe Connect Standard direct to your own Stripe account — is operationally manageable for studios with even a small operations function and produces compounding benefits over time: the dispute history accumulates against your account, the merchant identifier stays consistent, the lender visibility builds, and any future migration preserves the payment-processing relationship intact.

For studios on existing bundled-processing platforms, the practical recommendation is to read your monthly statement carefully to see the actual rate you're paying, evaluate the Direct Debit cost difference if you have meaningful membership volume, and at your next renewal moment treat the payment-processing architecture as one of the five structural questions worth asking (alongside contract length, marketplace, data export, and pricing transparency). For studios choosing new platforms, Stripe Connect Standard direct is the structural answer.

Related reading: Junocal vs Mindbody for pilates studios in the UK, Junocal vs Momence for studio owners, the annual contract trap in studio software, and the state of pilates studio software in 2026 — the broader structural-question context. If you'd like to walk through your specific payment-processing architecture, hello@junocal.com gets a real reply from a real person, usually within a few hours.