Beyond Stripe Connect: Transitioning to PayFac
Framework for vertical SaaS companies. When to transition. How to prepare. Which payments provider to select.
Almost every vertical SaaS platform starts on Stripe Connect — and for most early-stage companies, that is the right call. Stripe's documentation is unmatched, the compliance surface is mostly handled, and a working embedded payments flow can be live in weeks. But past a rough $10M per year in processing volume, a "2.9%" headline rate quietly blends to 3.4–3.8% once platform fees, payout costs, dispute fees, and add-on services stack up — and that delta compounds fast at scale. The decision that was obvious at $1M ARR deserves a hard look at $5M.
- Stripe Connect's real blended rate is not 2.9%. At scale, platform fees, payout costs, international card surcharges, billing fees, and dispute fees regularly push effective rates to 3.4–3.8% — worth modeling at actual volume before assuming Stripe is the cheaper option.
- The most important contract clause isn't price — it's token portability. Merchant tokens are trapped inside the issuing provider's vault; network tokens (issued by Visa or Mastercard) are portable. Confirm this in writing before signing, not during a future migration crisis.
- Owning merchant KYB data cuts migration timelines from 12 months to weeks. Platforms that let their PSP hold onboarding data face re-running full KYC and KYB for every merchant when they switch. Platforms that own it turn the same migration into a routing change.
- PFaaS is the right on-ramp for most vertical SaaS companies under $30M ARR. Full PayFac registration costs roughly $110K annually and takes 3–5 months to implement — the economics rarely justify it below meaningful processing volume.
- Merchant migration, not technical integration, sets the realistic timeline. Technical work takes 2–4 weeks. Getting an existing merchant base fully migrated and attach rate stabilized on a new provider realistically runs 6–12 months.
Where Stripe Connect actually sits on the payments ownership spectrum
Stripe Connect is not one product. Standard, Express, and Custom (now sold as Embedded Components) sit at meaningfully different points on the ownership and economics spectrum.
Standard is closest to a referral relationship — fast to launch, low liability for the platform, but thin economics. Stripe owns most of the merchant relationship. Custom can support something much closer to a real PayFac experience, with platform margin captured through application fees on direct charges. Two platforms that both say "we use Connect" can have very different economics depending on which mode they're running — worth confirming before assuming the economics ceiling is already known.
Where Connect is hardest to beat: cross-border coverage. It supports payouts in 45+ countries with FX handling most purpose-built alternatives still cannot match. For a genuinely global merchant base, that alone can outweigh everything else in this guide.
What Stripe Connect actually costs at scale
Beyond the advertised 2.9% + $0.30, Connect layers on real costs that don't appear in the headline rate:
- Roughly $2/month per active connected account
- 0.25% + $0.25 per payout
- +1.5% on international cards
- +1% on currency conversion
- 0.7% if using Stripe Billing
- 0.5% for Stripe Tax (which still doesn't file in most jurisdictions — Avalara or Anrok are typically required on top)
- $15 per dispute, regardless of outcome
Stack three or four of these and a "2.9%" headline rate blends closer to 3.4–3.8% on real volume. The first step before running any external evaluation is to get a custom pricing quote from Stripe itself. Above a certain volume, Stripe will negotiate custom platform pricing that shares more margin — many platforms that assume they need to switch actually just needed a better deal on the same stack. Get that number first. It's the baseline for every comparison that follows.
The alternatives, compared
The market is wider than it looks, but most of it is not actually competing for the same decision. Here is the shortlist worth evaluating seriously.
| Provider | Best for | Economics | Key limitation |
|---|---|---|---|
| Stripe Connect | Early-stage, online-first platforms | 2.9% + fees; blends to ~3.4–3.8% at scale | Economics capped; no direct path to full PayFac |
| Finix | Platforms scaling toward $100M+ GPV | Interchange-plus; strong unit economics | API-first — more integration work; North America–focused |
| Rainforest | Healthcare, home services, nonprofits — verticals mainstream underwriting handles poorly | Platform keeps customer relationship and data | Shorter track record; narrower geographic footprint |
| Tilled | Platforms wanting a transparent, tiered revenue share | Published tiers: roughly 70–80%+ of net margin at higher tiers | Smaller support footprint than Finix or Worldpay |
| Payabli | Platforms wanting a bundled white-label stack: payments, billing, and payouts in one API | White-label, revenue-share model | Newer entrant; thinner independently verified track record |
| Infinicept | Platforms targeting full PayFac registration within 24 months | ~$110K annual cost; live in 3–5 months | Higher fixed cost; build-enabler, not a turnkey processor |
| Stax | US SMB platforms with predictable, high-ticket transactions | Subscription pricing, not percentage markup | US-only; developer experience trails Stripe or Finix |
| Payroc | In-person-heavy verticals wanting flexible partnership structure | Flexible monetization; negotiated | Thinner public documentation; pricing opaque |
Worth a brief mention but not a full evaluation: Adyen for Platforms (the enterprise default past $20M+/month, with minimum volume commitments), Braintree (if customers expect PayPal or Venmo), Worldpay for Platforms (proven PFaaS at processor scale), and Shift4 (strongest in hospitality-heavy verticals with deep hardware and POS integrations).
Evaluation criteria to score every option against
Whatever shortlist is built, score it consistently on the same dimensions rather than comparing headline rates:
- Pricing structure & economics — flat rate vs. interchange-plus vs. subscription; what is the actual buy rate at current volume and at projected volume a year out? Insist on an interchange-plus quote from every provider for genuine comparability.
- Revenue share / monetization — is this a true processing-margin share, or a fee-on-top with a low ceiling? What net basis points does the platform actually keep, and can merchant-facing pricing be set independently?
- Integration complexity & developer experience — API and SDK quality, documentation, sandbox availability, prebuilt UI components, realistic time-to-first-transaction.
- Hardware — availability, quality, cost, and certification breadth, if there is any in-person requirement at all.
- Onboarding & sub-merchant underwriting — instant or bulk onboarding versus multi-day manual approval; who actually underwrites; how automated KYC/KYB is.
- Compliance & risk / liability ownership — who is the merchant of record; who owns PCI, chargeback, and fraud liability.
- Payout timing & float — settlement speed (next-day vs. T+2), instant-payout options and their cost, how much control the platform has over payout timing.
- International support — countries, currencies, cross-border fees; relevant once processing approaches $20M/month or the merchant base is global.
- Contract terms & exclusivity — length, exclusivity clauses, portability of merchant agreements and the tokenized card vault, and actual termination costs.
That last criterion deserves its own section.
What tokenization actually determines — and why it is the clause that makes a contract permanent
The 12–19 digit number on a customer's card — and the most sensitive piece of data in any card transaction. As a SaaS founder embedding payments, touching raw PANs directly immediately expands PCI DSS compliance obligations significantly. The goal should be to architect the payment flow so PANs are handled entirely by the payment provider, never passing through the platform's own servers.
A surrogate value that replaces a customer's PAN in your systems. For SaaS founders, this is the practical alternative to storing raw card data. When a customer saves a card for future billing — subscriptions, upgrades, seat expansions — the platform stores a token, not the actual card number. The payment provider maps that token back to the real card at charge time, meaning recurring billing capability is preserved without the liability of holding sensitive card data.
Most providers default to issuing merchant tokens — the card number is stored in that provider's vault, and the token they hand the platform only works inside their ecosystem. Switch providers, and every one of those tokens is worthless. Every stored card has to be re-collected from the customer.
A step beyond basic tokenization, where Visa or Mastercard themselves issue the surrogate credential. For SaaS businesses running subscription billing, this is particularly valuable: network tokens automatically update when a customer's card expires or is replaced, dramatically cutting involuntary churn from failed renewals. Checkout.com's analysis found a 10.3 percentage point improvement in authorization rates for platforms using network tokenization — for a SaaS business with high monthly recurring revenue, that improvement compounds significantly over time.
Network tokens, issued directly by Visa or Mastercard rather than by the processor, are tied to the underlying card account. They are portable across any provider that supports them, and they update automatically when a card is reissued.
Ask any provider being evaluated, explicitly: do you support network token issuance and passthrough for stored payment methods? Many do not by default. Per Preczn's analysis of vendor lock-in, contracts with 48–72 month terms and six-figure data release clauses are not hypothetical — they have happened. Token portability and data export rights need to be confirmed before signing, not discovered during a migration.
The security compliance framework governing any business that stores, processes, or transmits card data. For SaaS founders, understanding PCI scope is critical from day one — it determines how much compliance burden the platform carries. By using a payment provider that handles tokenization and vaulting, platforms can typically qualify for the lightest compliance tier (SAQ-A), avoiding the extensive audits required if systems touch raw PANs directly.
Who owns merchant onboarding data — and why it sets the migration timeline
Separately from card tokens, most PSPs retain the underlying KYB data — business registration, beneficial ownership, risk profile — collected during merchant onboarding. This is a structural lock-in feature, not an oversight.
A platform that doesn't own this data and wants to migrate 100 merchants to a new provider is often re-running onboarding from scratch for each one — a process that can stretch past a year. A platform that owns this data already holds the large majority of what a new provider needs, and can execute the same migration in a matter of weeks. Finix's migration guide and Stripe's own switching documentation both flag data ownership as the primary driver of migration complexity — not the technical integration itself.
Under Stripe Connect Standard, Stripe collects and owns identity verification almost entirely. Move to a white-label PFaaS relationship and the platform typically owns more of the onboarding experience — even though the provider still carries most of the underwriting liability, the platform's team is now designing the flow, fielding the "why do you need my SSN" questions, and often re-screening beneficial owners on an ongoing basis. Real, ongoing headcount, not a one-time integration task.
Treat token portability and data ownership as non-negotiable contract terms — they are what keep this decision from becoming permanent the moment it is made.
What changes operationally once the platform moves past Stripe's default
The org chart changes here too, not just the vendor.
Sales now has to sell a financial product with basis-point economics alongside the software subscription. Reps who default to matching a merchant's existing rate just to close the deal quietly erode take rate instead of growing it. ServiceTitan's early payments launch ran into exactly this — plus onboarding that stalled for months because merchants didn't understand why financial documentation was suddenly part of the sales process.
Customer success shifts from a pure retention function into a revenue-generating one. Instead of just protecting renewal, CS now owns converting non-paying merchants and resolving disputes that hit a merchant's actual cash flow. That is a different skill set and a different incentive structure than most CS teams are built around.
Product expands from a UX surface into critical infrastructure. A decline-rate spike or a held payout becomes a product incident, not a vendor problem.
Support becomes payments-literate or it becomes a liability. Disputes, onboarding blocks, and frozen accounts are high-stakes tickets a generalist support team without payments context typically cannot resolve — and a bad first experience with the new provider is often what kills a merchant's willingness to migrate at all.
Bridges works alongside payments and fintech founders to model the full economics of this transition — including what shifts in the org chart and finance function, not just what shifts on the fee schedule.
When orchestration is the answer instead of switching
Payment orchestration platforms (Spreedly is the clearest example) sit above multiple PSPs and route each transaction to whichever one fits best on cost, authorization likelihood, or payment method. Merchants running orchestration commonly see a meaningful lift in authorization rates and eliminate single-provider outage risk.
It is not free: platform fees commonly run $2,000–$10,000+/month on top of multi-provider integration complexity. Stripe's switching documentation notes that orchestration layers add meaningful overhead below certain volume thresholds. Below roughly $10–20M/month in processing volume or without a genuine multi-provider need, orchestration is a sophisticated-looking distraction rather than a real lever.
The migration playbook
The technical integration is rarely the bottleneck — most platforms complete it in 2–4 weeks. What takes months is everything downstream. Per Yeeld's billing migration checklist and Lithic's compliance program guidance, the following sequence holds across nearly every provider switch:
- Map every flow before writing a line of code: new merchant signup, onboarding, first payment, refunds, disputes, payouts, reconciliation, devices, regions, currencies, tax forms. Assign one owner per flow.
- Score 2–3 finalists against the evaluation criteria above, not ten. Weight them for the specific model. A marketplace cares most about payouts and negative-balance handling; a field-service platform cares most about terminal estate management. Test finalists in sandbox before committing.
- Get the complete pricing matrix on paper: processing, assessments, monthly fees, terminal costs, payout fees, instant-payout fees, FX, chargeback fees, platform fees, revenue share, SLAs, service credits, and — explicitly — token portability and termination terms. One spreadsheet, reviewed by legal and finance before signing.
- Design the account and token architecture deliberately: merchant/sub-merchant hierarchy, token strategy, how fee and transfer objects map to the platform ledger, idempotency and retry patterns, full webhook coverage with signature validation.
- Plan the merchant migration before the technical one: token portability mechanics, a customer communication schedule, self-service card-update flows, a day-one support hotline, re-KYC document checklists if required, and a clear dispute-handling handover.
- Pilot with a defined cohort first. Set explicit success thresholds — approval rate, time-to-onboarding, payout accuracy — run both providers in parallel, and keep a real rollback plan.
- Track attach rate weekly, by cohort, with a named owner. Treat it with the same rigor as churn, because it determines whether the new economics ever actually materialize.
Technical migration is measured in weeks. Merchant migration — getting the existing base onto the new provider and back up to a healthy attach rate — realistically runs 3–6 months to reach a stable floor, and 6–12 months to reach the actual ceiling. A platform that models only the technical timeline will show the board a number that is wrong by a factor of five or more.
Where purpose-built alternatives earn their premium
The case for a vertical-tuned provider over a generalist is strongest in recognizable patterns:
- Field service and home services platforms, where payout timing is tightly coupled to job completion and invoicing
- Healthcare SaaS, where HSA/FSA payment handling and patient billing involve reconciliation complexity generic processors handle poorly, and where vertical-specific underwriting has been shown to materially lift authorization rates for merchants mainstream risk models treat as marginal
- Legal and trust-accounting-governed verticals, where payment processing has to respect rules against commingling client funds with operating funds — a constraint a generic processor doesn't enforce and a purpose-built integration does by design
If the platform sits in one of these categories, weight vertical-specific underwriting and compliance fit more heavily in the evaluation than raw basis-point economics.
Frequently asked questions
Standard is closer to a referral relationship — fast, low platform liability, thin economics, and Stripe owns most of the merchant relationship. Custom (sold today as Embedded Components) can support something much closer to a real PayFac experience, with meaningful platform margin captured through application fees on direct charges, at the cost of more integration work and more of the onboarding experience sitting with you. Confirm which mode you're actually running before assuming you already know your economics ceiling on Stripe.
A merchant token is issued and controlled by your current provider — useful only inside their ecosystem, worthless the moment you leave. A network token is issued by the card network itself, tied to the underlying card account rather than to any one processor, and portable across providers that support it. If you care about ever being able to switch without a mass card-re-collection event, confirm network token support before you're locked into merchant tokens at scale.
A centralized store of payment credentials — card tokens, bank details, ACH mandates — held in network-standard formats independent of any single processor. It's what turns a future migration into a routing-rule change instead of a customer re-enrollment campaign. Worth architecting toward even on Stripe, before you have tens of thousands of stored cards to migrate later.
When switching processors is prohibitively expensive or disruptive because of proprietary (non-exportable) token formats, long contracts with punitive exit fees, or gateways that only interoperate with one provider's own stack. It's usually invisible until you try to leave — which is why token portability, data-export rights, and exit-fee terms need to be checked before signing, not discovered during a crisis.
It means holding the merchant onboarding (KYB) data yourself rather than only your PSP holding it. A platform that owns this data typically already has the large majority of what a new provider needs to onboard the same merchants, turning a migration that could otherwise take the better part of a year into a matter of weeks.
KYC verifies an individual — name, address, date of birth, taxpayer ID. KYB verifies the business entity — legal name, location, EIN, and often beneficial ownership above a threshold (commonly 25%, sometimes lower depending on the banking partner). Under Stripe's default flow, Stripe owns most of this. Under a white-label PFaaS relationship, your team typically owns more of the onboarding experience and the ongoing re-screening, even though the provider still carries most of the underwriting liability — real, ongoing operational work, not a one-time build.
Once you're processing roughly $10–20M/month or have a genuine multi-region or redundancy requirement no single provider meets. Below that, orchestration adds real cost ($2,000–$10,000+/month) and integration complexity without enough volume to justify it — a sophisticated-looking distraction more than a real fix.
Often, yes — worth pricing before you assume migration is necessary. Stripe (and most providers at real volume) will negotiate custom platform pricing that shares more margin than the default rate card. Get that number as your baseline before running an external evaluation; sometimes the best outcome of a “should we leave Stripe” process is a better deal to stay.
Less often the technology, more often underestimated dependencies: payment tokens that can't be transferred without forcing customer re-enrollment, merchant onboarding data you don't own and have to re-collect, invoice numbering or reconciliation continuity breaking silently, and — most commonly — a technical migration that goes smoothly while merchant attach rate on the new provider stalls because nobody owned driving it.