How to Choose the Right Billing Architecture for Your SaaS Before You’re Trapped in the Wrong One

Most founders treat billing as an afterthought. They pick Stripe, wire it up in a weekend, and ship. That works fine until you need usage-based pricing, trial-to-paid conversion logic, multi-seat plans, invoice customisation for enterprise, or a refund policy that isn’t manually managed in a spreadsheet. By then, the billing layer is woven into the core of the product and ripping it out costs $30,000-$80,000 AUD in rebuild time, data migration risk, and lost subscription continuity. We’ve seen it. It’s not a fun conversation to have.

The decision you make in week two of your build will shape what your pricing model can even support two years from now. That’s worth a few hours of architecture thinking before you write a single line of code.

There Are Really Only Three Architectures Worth Considering

Every billing system you’ll encounter sits somewhere on a spectrum between three approaches. Each has a place. The mistake is choosing the wrong one for where your product is actually headed – not where it is today.

1. Stripe Billing (or Paddle) wired directly to your app. You build subscription logic directly against the Stripe API. Plans, trials, webhooks for lifecycle events, customer portal. Simple, fast, cheap to start. Covers 80% of early SaaS use cases.
2. A billing abstraction layer you build yourself. Your app talks to an internal billing service that talks to Stripe (or whatever). The product code never calls Stripe directly. You own the state machine. More upfront work, but your pricing model becomes a configuration problem rather than a code change.
3. A dedicated billing platform like Chargebee, Recurly, or Orb. You’re buying a domain-specific product to handle the complexity. Higher cost ($500-$2,000+/month AUD depending on revenue), but serious usage-based metering, dunning, revenue recognition, and enterprise invoicing come pre-built.

The honest answer on which to pick: it depends entirely on the complexity of your pricing model and how frequently you expect it to change. Not how complex it is on day one – how complex it could become in 18 months.

The Direct Stripe Integration Trap

Stripe is genuinely excellent. We use it on almost everything we ship. But there’s a specific failure mode we see over and over: a founder wires Stripe Billing directly into their application layer, plan IDs hardcoded or stored in a config, subscription state pulled live from Stripe on every relevant request, pricing logic scattered across three controllers and a webhook handler.

That works until the moment you need to:

• Support a legacy plan that Stripe no longer has a product record for
• Change how a feature maps to a tier without disrupting current subscribers
• Add a usage-based component to a flat-rate plan
• Handle a customer who has two separate subscriptions that affect each other’s entitlements
• Migrate to a different payment provider (even partially, for a new market)

At that point, you’re hunting through application code to find every place a plan assumption was baked in. The cost of that work, on a live product with real subscribers, is not trivial. We scoped a remediation for a B2B SaaS last year where the direct integration was only 14 months old, and getting to a clean abstraction layer was a six-week engagement. That’s real money for a company in growth mode.

When to Build a Billing Abstraction Layer From the Start

Here’s the rule we use: if you can describe your pricing model in one sentence and you don’t expect that to change significantly in the next year, go direct. If you’re already hedging – “we’ll probably add seats”, “we want to try usage-based for the API tier eventually”, “we might do a per-workspace model” – build the abstraction layer now, while the codebase is small.

What does that actually look like in practice? At minimum, it means your application code asks an internal entitlements service whether a given customer can do a given thing. It doesn’t query Stripe directly. The service knows about plans, overrides, add-ons, trials, and grandfathered pricing. Stripe is the payment engine underneath it – not the source of truth for what a customer is allowed to do.

The build cost for a clean billing abstraction layer on a greenfield project is roughly $8,000-$15,000 AUD in additional scope, depending on complexity. That sounds like a lot when you’re about to spend $60,000 on an MVP. Spend the $10,000 now and you’ll have a billing system that can support five pricing experiments and two model changes without developer panic. Skip it and you’ll spend $40,000 fixing it later, on a product that’s now carrying users and live revenue.

When a Dedicated Billing Platform Actually Justifies the Cost

Chargebee and Recurly often come up in early-stage conversations as if they’re the sensible “enterprise-ready” choice. Sometimes they are. More often, a founder is paying $800/month AUD for features they won’t use for three years, while also coupling their product to another SaaS dependency with its own API quirks and downtime profile.

The genuine use cases for a dedicated billing platform from early stage:

• You are building a usage-based product where metering is core to the value proposition from day one – think API products, compute-adjacent SaaS, anything that bills per event or per unit consumed
• You are targeting mid-market or enterprise and need invoice customisation, purchase order support, and revenue recognition reporting that aligns with your customers’ procurement process
• You are operating across multiple currencies and tax jurisdictions simultaneously, not eventually

If none of those apply on launch day, you almost certainly don’t need Chargebee yet. Orb is worth a look if usage-based metering is legitimately central – it’s purpose-built for that use case and the API is well-designed. But don’t bring in platform complexity to solve a problem you haven’t got yet.

The Dunning and Failed Payment Problem Nobody Plans For

Failed payments are boring until they’re not. For most early SaaS products, involuntary churn from failed payments runs somewhere between 1% and 4% of subscribers per month. At small scale, you barely notice. At $100K MRR, you’re potentially losing $1,000-$4,000 a month to cards that could have been recovered with a sensible retry schedule and a well-timed email.

Whatever billing architecture you choose, decide on dunning logic before you launch – not when you first see a spike in failed payments on a Wednesday morning. Stripe’s built-in smart retries are a reasonable starting point. What they don’t do is send your customers a branded, well-worded recovery email with a direct link to update their card, timed to land when they’re actually likely to act on it. That’s something you build once and leave running. It compounds.

The dunning sequence we typically configure: immediate retry attempt on failure, email on day one, retry on day three, email on day five, final email and account pause warning on day ten, retry and account flag on day fourteen. Adjust the cadence for your customer segment – enterprise customers need a softer, more personal touch than a consumer app. But have the sequence. Don’t improvise it live.

What to Decide Before You Write Any Billing Code

Before the first billing-related line of code lands in your codebase, make sure you’ve answered these explicitly:

• Who owns subscription state? Stripe, or your database? Pick one source of truth and be deliberate about it.
• How will you handle plan changes mid-cycle? Proration logic is surprisingly fiddly. Stripe can do it, but you need to decide your policy first.
• What does “cancelled” actually mean for your product? Immediate access removal? End of billing period? Grandfathered access to existing data?
• How will enterprise customers pay? If there’s any chance of invoice-based billing, your architecture needs to accommodate it from the start – retrofitting it is painful.
• What happens to billing data if you switch providers? Portability matters. Exporting your subscriber list, payment history, and plan states cleanly should be possible from day one.

These aren’t rhetorical questions. Get them answered in a document before you scope the build, not after the first customer complains their subscription isn’t working the way they expected.

Billing architecture is one of those areas where the cost of a two-hour design conversation is almost always negative – it saves more than it costs, every time. If you’re about to start a SaaS build and haven’t locked this down yet, talk to Amora about your build before the first sprint starts. It’s a much better conversation than the one where we’re working out how to migrate 3,000 live subscribers without breaking anything.