The hidden cost of payment-processor lock-in

Payment software is easy to compare badly. A checkout may display Stripe, Square or another familiar name while the commercial relationship, account control and migration options differ behind the scenes.

The useful question is not simply "Does this use Stripe?" It is: what will the studio still control if it leaves the scheduling platform?

Junocal is included because this is Junocal's blog. It uses Stripe Connect Standard and does not add a Junocal processing markup. That is a product choice, not proof that every other architecture is expensive or unsuitable.

The account relationship matters

Stripe's official documentation describes a Standard connected account as a conventional Stripe account: the business has a direct relationship with Stripe, can log in to the Dashboard and can process charges independently.

Stripe's OAuth documentation also says that charges, customers, invoices and other data created for a Standard account are visible in that account. If the business connects other platforms, those platforms can access that data within their granted permissions.

That creates useful continuity, but it is not universal portability. A new studio platform must still understand and support the relevant Stripe objects. A customer record existing in Stripe does not guarantee that a new scheduler can automatically reconstruct a membership, class credit balance or mandate created by the old platform.

Other payment arrangements can also be valid. A platform may manage onboarding, risk, payouts and support more centrally, and that can reduce operational work for a small business. The trade-off must be evaluated from the applicable contract rather than a generic label such as "bundled."

Seven questions to ask before signing

1. Who has the direct processor relationship?

Ask whether the studio can log into its own processor dashboard, see charges and payouts, manage disputes and update bank details without going through the software vendor.

2. Who controls payouts and reserves?

Document the payout schedule, minimums, reserve policy and who can delay or reverse a payout. A direct account can still be subject to processor risk controls.

3. What fees are mandatory?

Collect the processor percentage, fixed fee, platform percentage, refund fees, dispute fees, international-card charges, currency conversion, bank-debit pricing and any monthly minimum. Published headline rates are starting points, not a substitute for the account's schedule.

4. What survives cancellation?

Ask what dashboard access, transaction history, customer records, invoices, tax documents and dispute evidence remain available after the software subscription ends. Get any read-only period or export commitment in writing.

5. Can recurring payment authority be reused?

Saved cards, network tokens and bank-debit mandates are sensitive payment credentials. Their reuse depends on the processor, account relationship, authorization wording, region and new platform's integration. Never promise a seamless mandate transfer based only on a CSV export.

6. Can another platform connect the same account?

A Standard Stripe account can be connected to compatible applications, but the new product must support the connection and the objects you need. Run a technical migration test before the cancellation date.

7. How are refunds and disputes handled?

Confirm who responds, whose balance funds a refund or dispute, and where evidence is stored. The support model can matter as much as the fee rate.

Calculate the effective processing rate

For a chosen period:

effective processing rate =
  (processor fees + platform payment fees + payment add-ons)
  ÷ gross processed volume

Use actual statements where possible. Separate the software subscription from payment fees unless the contract bundles them. Model the business's real mix of domestic cards, international cards, wallets and bank debits.

Avoid a generic claim that a competitor adds "a few tenths of a percent." Some vendors publish a rate, some negotiate it, and some charge separate platform fees. A claim belongs in a comparison only when the current official page or the studio's written quote supports it.

A migration test is better than an architecture promise

Before switching:

1. Export the client, product, subscription and transaction data available from the current system.
2. Identify recurring mandates and saved methods separately from ordinary customer records.
3. Connect the destination platform to a test or existing processor account where supported.
4. Recreate one representative pack, membership, refund and failed-payment case.
5. Confirm what must be re-authorized by clients.
6. Keep access to historical statements and dispute evidence for the required retention period.

What Junocal's approach does and does not mean

With Junocal, the studio connects a Stripe Standard account. Stripe maintains the direct account relationship and Dashboard, while Junocal creates supported payment objects for the studio. Junocal does not add its own processing markup.

Stripe still charges its applicable fees. Charges can fail, saved methods are not guaranteed to be reusable in every future integration, and bank-debit availability depends on the account and transaction. A connected account reduces one form of platform dependency; it does not eliminate payment regulation or migration work.

Bottom line

Processor lock-in is not a single percentage. It is the combination of account ownership, data visibility, reusable payment authority, contract terms and the practical cost of reconstructing recurring revenue elsewhere. Ask precise questions, calculate from the written fee schedule and test an exit path before relying on a marketing label.