How a SaaS startup launched a two-sided marketplace with Stripe Connect

The money problem every marketplace founder hits

A two-sided marketplace is a payments business wearing a product. Buyers pay, the platform takes a cut, and sellers expect to be paid in full and on time. That sounds like one transaction, but it is really four jobs stacked together. Onboard the seller and verify who they are. Take the buyer’s payment. Split out the platform fee. Pay the seller. Get any one of them wrong and you have either lost money or broken trust, and in a marketplace trust is the whole asset.

For an early-stage Australian B2B startup, the trap is treating payments as a feature to build later. It is not a feature. Holding and moving other people’s money brings identity checks, payout scheduling, dispute handling, a ledger that has to balance, and financial-services obligations that come with holding funds. None of that is the product the founders set out to build, and all of it has to be right before a single real dollar moves.

Then there are the edge cases, which is where marketplaces quietly bleed. A buyer is refunded after the seller has already been paid out. A charge is disputed weeks later. A payout to a seller fails because their bank details changed. A capture is partial. Each one is a moment where money has to move backwards or sideways, and a system that only handled the happy path now owes someone money it cannot account for. Building all of this from scratch is months of work an early-stage team does not have, on a problem that is regulated and unforgiving.

A custom marketplace on Stripe Connect

The build that works keeps the marketplace custom and hands the regulated money movement to Stripe Connect. The application itself, the listings, the matching, the buyer and seller experience, is built bespoke on AWS with a PostgreSQL database, because that is the product and it has to fit how this particular marketplace works. The money, though, runs through Stripe Connect, and that choice is the one that earns its place at the centre of the design.

Stripe Connect is the part that lets a startup move money between many buyers and many sellers without becoming a payments business. It onboards sellers, runs the identity and business verification that comes with paying third parties, takes the buyer’s payment, splits out the platform fee, and pays the seller on a schedule. Because Stripe moves the funds, the platform never holds them itself, which keeps the startup clear of the licensing and the compliance weight that holding money would bring. Building that money movement, the onboarding, the payouts and the financial-services compliance by hand would cost months and carry real regulatory risk. Connect makes it configuration and integration rather than a payments product to design from nothing.

The custom layer wraps around it. PostgreSQL holds the platform’s own ledger, the record of what is owed, paid and held, so the marketplace always knows its own position rather than reading it back from Stripe alone. The application runs on AWS, with the marketplace logic, the listings and the fee rules all built to fit the business. Stripe and the platform stay in step through webhooks, so when a payment, payout or refund happens, the platform’s books update to match.

We split the marketplace logic from the money movement on purpose. The marketplace will change often as the product finds its shape. The money movement must not. Keeping Stripe Connect as the regulated core and the custom build around it means the team can iterate on the product without touching the part where mistakes cost real dollars.

Building it, and where it got hard

The integration was rarely the hard part. The edge cases were, and one stands in for the rest. The refund after payout.

In the happy path a buyer pays, the fee is split, and the seller is paid. The trouble starts when a buyer is refunded after the seller already has the money. Now the platform has to recover funds that have left the building, and a system that only modelled the forward flow has no idea how. Early in the build this was exactly the gap. The flow handled payments and payouts cleanly, but a refund against an already-paid order left the ledger out of balance and the money unaccounted for. In a marketplace, “mostly right until someone asks for their money back” is not good enough.

The fix was to design the ledger and a state machine around the real edge cases rather than the happy path. Every order moves through explicit states, paid, held, paid out, refunded, disputed, reversed, and the model knows how to claw back or offset a payout when a refund lands after the fact. We used Stripe Connect for the regulated money movement and the KYC, then made the platform’s own books the source of truth for what was owed.

Two technical decisions made it reliable. Webhook handling was made idempotent, so a Stripe event that arrived twice, as they sometimes do, was never applied twice and never double-counted a refund or a payout. And we built reconciliation that proved the platform’s ledger in PostgreSQL matched Stripe’s record to the cent, run continuously, so any drift surfaced immediately instead of at the end of the month. None of this is glamorous. All of it is the difference between founders who trust their own books and founders who do not.

What changed

In a representative build the marketplace reached a working payments-and-payouts flow in weeks rather than the months a hand-built money-movement system would have demanded. The team launched with sellers onboarding through Stripe Connect, buyers paying, fees splitting out and payouts running, without the startup ever holding funds itself.

The books held up too. Seller payouts and fee splits reconciled against Stripe to the cent, so the founders could trust their numbers from the first transaction rather than hoping they balanced. And the cases that usually lose a marketplace money, the refund after payout, the disputed charge, the failed payout, were modelled before launch, so they were handled paths rather than production surprises.

These figures are illustrative. They describe the pattern we see rather than a published result for a named startup. The shape is the point. The startup shipped the marketplace that is actually its business, on a custom build it controls, while the regulated money movement sat with Stripe Connect where the compliance and the payout machinery already exist.

Where this fits

A custom marketplace on Stripe Connect is one application of our Custom Software service, built around a payments platform, for an early-stage technology and software business. It suits the contained, high-stakes problem of moving money between buyers and sellers, where the value comes from getting the ledger, the edge cases and the reconciliation right rather than rebuilding payments from scratch. If you are standing up a two-sided marketplace and the money movement is what stands between you and launch, the place to start is to map your buyer, seller and fee flows and decide which parts Stripe Connect should carry.