When it comes to traditional web platforms that involve payments, Stripe is the first rail we reach for. Not because we're Stripe resellers — we build financial platforms, and Stripe happens to be the best tool in the market for most of what we get asked to do.
01Intro
When it comes to traditional web platforms that involve payments, Stripe is the first rail we reach for. Not because we're Stripe resellers. We're not. We build financial platforms, and Stripe happens to be the best tool in the market for most of what we get asked to do.
Here is the thing people get wrong about it.
Stripe is not hard. Stripe is exceptional. The documentation is better than most teams' internal documentation, the SDKs are clean, and the primitives are well chosen. If all you need is a checkout page on a Shopify-style product, Stripe really is plug and play. A decent engineer can wire it in over a weekend if not in hours.
The problem starts when the product is not a checkout page. It is a platform. A marketplace with multiple parties. A billing engine for a SaaS. A mobile app that holds user balance and runs subscriptions on its own schedule. All of these sit inside a broader problem: building a financial platform. That problem is not Stripe's problem. That problem would exist with any rail. It existed before Stripe. It will exist after Stripe. Stripe does not cause it, and Stripe cannot solve it for you.
What Stripe will do, if you know what you're building, is handle around 80 percent of the operational plumbing cleanly. What it cannot do is tell you what you are building.
We've built across all of the shapes that actually require this understanding. Marketplace, SaaS billing, mobile-native consumer. Here is what we've learned.
02The gap between "integrates Stripe" and "runs on Stripe"
Most teams that come to us have done one of two things. They've dropped a Stripe Checkout link into a product and now want to evolve it into something multi-party. Or they've read the docs, decided the whole thing looks manageable, and scoped a three-week build for what is structurally a twelve-week build.
The gap is not in Stripe. The gap is in the thinking that happens before you touch Stripe. Stripe Checkout and a hosted payment link really are plug and play. That is what they are for. The moment you move into Stripe Connect, custom subscription logic, held balances, multi-currency settlement, or anything where the platform itself is the merchant of record, the shape of the work changes completely. You are not integrating a payment form. You are running a payments platform on someone else's rails.
That is a different discipline. It requires thinking about money flows, liability, timing, failure modes, reporting, and compliance before a line of code gets written. Stripe gives you the primitives. You still have to design the platform.
A few things teams consistently underestimate.
Marketplaces are marketplace-shaped, not payment-shaped. Stripe Connect is not a feature you wire in. It is the infrastructure for the financial model of your business. Who onboards? Who owns the merchant relationship? Who holds funds, and for how long? What happens when a connected account fails KYC three months in? These are product and operational decisions. Stripe Connect executes them. It does not make them for you.
Webhooks are a distributed systems problem, not a Stripe problem. Stripe's events are at-least-once, not exactly-once. That is not a quirk of Stripe. It is the nature of event-driven systems. If you do not build idempotency properly, you will double-settle, double-refund, or double-invoice. Any rail has this shape. Stripe is more forgiving than most.
Reconciliation is a finance discipline. Stripe's dashboard is not your accounting system. If you are moving money between parties, someone has to reconcile what Stripe settled, what the platform earned, what tax was applied, and what hit each party's bank account. That is process and reporting work, not integration work. It exists whether you use Stripe, Adyen, or direct NPP. It is nearly always missed in scope.
Australian specifics matter more than teams think. Most Stripe content is US-flavoured. Real AU implementations touch PayTo, GST handling, ATO-compliant invoicing through Stripe Invoices, and surcharging rules that vary by state. None of that is hard. All of it has to be explicitly scoped.
None of these are Stripe problems. They are financial platform problems. The reason people mistake them for Stripe problems is that Stripe is usually where the pain surfaces, because Stripe is usually where the platform meets the real world.
03Three times we leaned on Stripe because we understood what we were building
We shipped a multi-party marketplace on Stripe Connect. A buyer pays upfront for a bundle of services, multiple providers deliver, and a coordinating party confirms release. Funds sit with the platform, then settle automatically, with tax documentation issued on behalf of each provider. The interesting work was not the Stripe integration. It was modelling every way a provider's account could end up in a state that blocked payout, and deciding how the platform should respond. Once that model was clean, Stripe executed it cleanly.
We built an automated billing layer for a SaaS platform on Stripe Billing and Subscriptions. Lifecycle events flow through Stripe as a source of truth, the client's admin dashboard reads off that, tax is handled by Stripe Tax, invoices generate automatically, and PCI scope stays off the client entirely. This was the closest of the three to "plug and play", and even this took real design work to decide what lived in Stripe and what lived in the client's platform. The simple Stripe build still required a proper product conversation.
We built a mobile-native consumer payments app with Apple Pay and Google Pay as first-class top-up methods, and a custom subscription engine that debits a held in-app balance rather than charging a card on a cadence. Stripe Billing was not the right tool here. The business needed to own subscription logic end to end. So we used Stripe for the rails (Payment Intents, Setup Intents, Connect Express for merchant payouts) and built the subscription engine above them. That distinction, using Stripe as a rail rather than as a product, is where most of the interesting fintech work sits. None of it was possible without understanding the financial model of the app first.
04What we actually think about Stripe
Stripe is one of the best pieces of infrastructure in software right now. It clears the table for almost any web2 payment shape. The alternative in Australia is stitching together bank feeds, direct PayTo integration, manual KYC, bespoke payouts, and a compliance program. That is a viable path, but it is a twelve-month program, not a product decision. Stripe gives us an eight-week path to the same operational capability at the cost of some platform rent and some vendor dependency.
We are not loyal to it. If a client's model actually needs direct NPP integration, or they are better served by Adyen, or they are building something where Stripe's fees structurally do not work, we will say so. We've had conversations that ended with "you don't actually want Stripe for this." We would rather have that conversation on day one than six months in.
What we are loyal to is understanding the platform before we choose the rail. The teams that get into trouble with Stripe are almost never the teams that chose Stripe badly. They are the teams that skipped the financial platform design, picked a rail that looked easy, and assumed the rail would teach them the domain. It will not. No rail will.
05The next two years, and what they mean for AU builders
Two things on Stripe's roadmap worth watching closely.
Stripe Treasury, the embedded banking product, remains US-only. Financial Accounts, card issuing, yield on balances, real account numbers that belong to your users. When this lands in Australia, platforms will be able to offer an in-product wallet with a real account behind it, without holding an AFSL or a banking partnership themselves. That is a significant shift for marketplaces, platform businesses, and anything where a held balance is currently a workaround. The timeline is unclear. Stripe has not announced one, and the AU version will need APRA-regulated partners, PayID and NPP integration, and a licensing story. We won't speculate on when. We will say that the acquisition of Bridge for around 1.1 billion USD tells you embedded finance and stablecoin rails are the direction, not a side bet.
The Bridge side of that story is the more interesting one for us. Stablecoin payouts through Stripe infrastructure change the cost structure of cross-border payment flows in a way local bank rails cannot compete with. Any AU platform paying international contractors, settling cross-border marketplace balances, or managing treasury across jurisdictions should be paying attention. This is where our blockchain work and our fintech work actually converge, and where the next wave of product opportunity sits.
Agentic Commerce is further out in real terms. The Stripe Agent Toolkit is live and usable today in Python and TypeScript, and we are exploring it with clients building AI workflows where agents need to take payment, manage subscriptions, or handle billing. The agent-initiated purchasing side, virtual card issuance to AI agents with spend controls, is still US and UK-focused because it leans on Stripe Issuing.
06Wrapping it up
Stripe is brilliant. That is precisely why it can be dangerous in the wrong hands or incredibly cumbersome. It makes financial infrastructure look like a checkout integration, and teams charge at it without thinking about the platform underneath.
We build financial platforms for a living. Stripe is usually our default rail. It is not our religion. If you are working through something in this space and want a second set of eyes before you commit to a rail, the conversation is worth having.
Get in touch: labrys.io/contact