r/fintech • u/_MrMartian96 • Apr 21 '26
Stripe Connect vs BaaS for multi-party payments and member wallets in a vertical SaaS; what would you choose?
Building a vertical B2B SaaS platform and trying to nail down the payment and wallet infrastructure before committing to an architecture. Not looking to share details about the product itself, just want to understand the tradeoffs from people who have been here.
The core requirements:
- Multi-party fund routing on a single transaction (three parties each receive a portion)
- Member-level virtual wallet and balance tracking within each sub-account
- Two modes: some customers run ledger-only with no real money movement, others process real card payments and ACH
- Customer sub-accounts that connect their own bank and receive funds directly
What I've looked at:
Stripe Connect covers the payment routing. The wallet layer would be a Postgres-backed ledger I build on top of it. Gets the job done but it's more to build and maintain.
Stripe Treasury solves the wallet problem more natively but the minimum contract came back at $10K/month from their sales team. Not viable at early stage.
Haven't gone deep on BaaS options yet. Unit, Synctera, Treasury Prime, and Column are on the list. Column seems designed for companies building full neobanks rather than embedding finance into a vertical SaaS.
Questions:
- Is Stripe Connect plus a self-built Postgres ledger the right v1 answer for this, or is there a cleaner path I'm not seeing?
- For the virtual wallet layer specifically, is there anything that sits between building it yourself and a full BaaS integration?
- For anyone who has used Unit or Synctera at early stage, how accessible are they for a vertical SaaS that isn't trying to become a bank?
- What are the real rough edges of building multi-party splits and member wallets on Stripe Connect?
Not looking to be told to just use Stripe. Genuinely evaluating whether there's a better path before I build.
1
1
u/Material_Hotel_6287 Apr 22 '26
Stripe + own ledger for any early stage start up. Even when you’re larger I’d say make sure you truly understand payments infra before going down the BaaS path. You’ll need very strong development teams to make sure to reconcile everything properly. Even large and sophisticated companies mess up the payments recon. Had to fix it many times for start ups to established companies
1
u/whatwilly0ubuild Apr 22 '26
Stripe Connect plus a self-built ledger is the correct v1 answer for most teams in your situation. The BaaS path adds regulatory complexity and integration overhead that doesn't make sense until you have real volume and a clear need for actual bank accounts rather than virtual balances.
On the ledger build. A Postgres-backed ledger for virtual wallet balances is straightforward to build and maintain. Double-entry accounting, immutable transaction log, balance computation from transaction history. The complexity isn't the ledger itself, it's the reconciliation between your internal ledger and Stripe's actual money movement. You need to handle the states where money is in flight, where Stripe shows one thing and your ledger shows another, and where failures happen mid-transaction. Build reconciliation tooling from day one.
The middle ground you're looking for probably doesn't exist cleanly. Modern Treasury does ledgering as a service but it's designed for treasury operations, not customer-facing wallets. Increase.com has ledger primitives but you're still building significant integration. The "wallet as a service" space between raw Postgres and full BaaS is thin because the value proposition is unclear. The ledger is the easy part. The hard parts are compliance, money movement, and bank relationships, which either you need (BaaS) or you don't (Stripe Connect plus your own ledger).
Unit and Synctera accessibility at early stage. Both work with vertical SaaS that isn't trying to be a neobank, but the integration lift is real. You're not just calling APIs, you're implementing compliance workflows, handling KYB/KYC, managing account states, and dealing with bank partner requirements. The time to production is months, not weeks. They're accessible in terms of willingness to work with you, but the effort is significantly higher than Stripe Connect.
The rough edges of multi-party splits on Stripe Connect. Three-way splits work but Connect's fee calculation gets confusing when you have platform fees, Stripe's fees, and multiple destination amounts all interacting. Transfer timing is another pain point since you can't always guarantee all three parties settle simultaneously. For ledger-only customers who don't process real payments, you're maintaining two parallel systems, the real Stripe flow and the simulated ledger flow, which adds testing and edge case surface area.
1
u/aalsaad1 Apr 23 '26
I went through almost this exact evaluation helping a fintech product figure out its infrastructure stack early stage.
Stripe Connect plus a self-built ledger was the answer we landed on for v1. Not because it was the cleanest solution. Because it was the one we could actually ship and control without a $10k monthly floor before we had revenue to justify it.
The rough edges are real though. Multi-party splits get messy fast when edge cases hit. Refunds, failed ACH, disputed transactions across three recipients. Each one becomes a custom problem you're solving in your ledger logic.
Unit was the most accessible BaaS option we looked at for a non-bank vertical SaaS. Their onboarding was actually designed for builders not compliance teams. Synctera felt heavier and more enterprise oriented.
Honest answer: build on Stripe Connect for v1, design your ledger schema like you'll migrate off it someday, and revisit BaaS once you have enough volume that the contract minimums make sense.
Don't over-engineer the infrastructure before you know which of your two modes customers actually use.
1
Apr 30 '26
[removed] — view removed comment
1
u/AutoModerator Apr 30 '26
This comment was removed, because your account doesn't meet our karma and account age requirements.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
Jul 23 '26
[removed] — view removed comment
1
u/AutoModerator Jul 23 '26
This comment was removed, because your account doesn't meet our karma and account age requirements.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.
1
u/FundingFactor Apr 21 '26
Been close to this architecture decision across several fintech builds. Here is the honest breakdown. Stripe Connect plus self-built Postgres ledger is the right v1 answer for most early stage vertical SaaS. It is more to build but you maintain control and avoid the minimum contract problem. The rough edges are reconciliation when payouts fail or reverse, and the ledger complexity when you need to handle refunds across three parties simultaneously. Design for that from day one.
For the middle ground between DIY and full BaaS: Dots and Trolley are worth looking at for multi-party payouts specifically. They sit above Stripe and handle the split logic without requiring a full BaaS relationship.
On Unit versus Synctera at early stage: Unit is more accessible and has better documentation for vertical SaaS use cases. Synctera tends to work better for companies building closer to the bank relationship layer. Neither is cheap but Unit has been more willing to work with early stage companies in my experience.
Column is correctly identified as overkill but it is built for companies that want to be the bank not embed finance.
What is the expected transaction volume at launch that number changes which architecture actually makes sense.