Stripe Billing Fees vs. Paddle: What Early-Stage SaaS Founders Should Know

By Jan Hilgard, Tech Entrepreneur at Discury · AI-assisted research, human-edited

Editor's Take — Jan Hilgard, Tech Entrepreneur at Discury

What strikes me reading these threads is how often founders view billing as a simple integration task rather than a core architectural decision. I've watched this pattern repeat in conversations with SaaS operators across the 790+ threads we index at Discury — a founder ships a Stripe Billing integration, sees it handle recurring charges seamlessly, and concludes "we're done with billing," when the ICP and volume models were always the bottleneck. The code is rarely the issue; the workflow is.

The second trap is the "all-in-one" fallacy. Threads are full of debates about Stripe's ease of use versus the overhead of managing a dedicated billing engine. The real signal is whether your billing model is "per-seat" or "per-usage." When the trigger (API requests, LLM tokens, compute time) is variable, the 0.7% volume tax washes out your margins faster than you anticipate. When your model is simple per-seat, the convenience of Stripe is often worth the premium.

If I were starting a B2B SaaS today, I'd spend the first week building a modular billing abstraction. I would keep the payment processor (Stripe) for the transaction itself but move the billing logic (invoicing, metered usage, credit notes) to a separate system. The founders in this sample often invert this, locking their revenue logic inside a proprietary API. The threads we monitor show that "un-locking" from that ecosystem is significantly more painful than building it right from day one.

Stripe Billing Fees: The 0.7% Shadow Tax

Stripe Billing pricing has evolved from a simple subscription tool into a comprehensive engine that now carries a 0.7% fee on all billing volume. This figure, reported in one HN discussion regarding deprecation notices, represents a shift from previous pricing models. For founders, this is not just a rounding error; it is a recurring cost that scales linearly with revenue, independent of the actual transaction processing costs.

As u/binarymax noted in this HN discussion regarding Stripe Billing changes, the move to a single comprehensive plan forces a pricing change that many users characterized as significant. One founder in an HN thread on billing migration noted that managing recurring charges via Stripe Billing costs 0.5% on top of standard payment processing fees. When these fees are aggregated, the total cost of payments can hit 2% to 4% of total transaction volume. This "double-dip" structure—charging for processing and then again for the billing logic—is the primary driver for teams moving toward open-source alternatives.

The second-order consequence is the "visibility trap." Because Stripe bundles these fees into the payout, founders often fail to account for them in their Cost of Goods Sold. In a thread discussing the economics of billing, u/corentin88 pointed out that ignoring this drag leads to inaccurate CAC-to-LTV calculations, masking the true profitability of high-volume segments.

Stripe Billing for Usage-Based Models

Founders building usage-based SaaS, particularly those handling API requests or data storage, face unique friction with standard subscription tools. One HN discussion on billing flexibility highlights that while Stripe Billing handles per-tier pricing well, it often struggles to provide the granular, per-usage tracking required for modern infrastructure.

As u/raiyu explained in an HN thread on Stripe Billing, the service provides an automated recurring billing approach for businesses running static monthly subscriptions or metered approaches like $0.02 per SMS. The challenge for startups is that usage volume can be highly volatile. A standard 0.7% fee on every unit processed through a billing engine can consume the margins of a thin-margin API wrapper. In one HN thread about Lago, founders emphasized that composability is the key—using only the parts of a billing system that match the specific business model rather than paying a flat percentage for a "black box" system.

Shopify App Store Governance and Payment Lock-in

Platform risk is a recurring theme in the discussions around billing API enforcement. In one HN thread regarding Shopify partner governance, a developer reported receiving a stern warning from Shopify for using external Stripe billing instead of the platform's native Billing API. Shopify’s requirement for a 20% revenue share on apps listed in their store is a stark reminder of the "moat defense" that large platforms employ.

As u/ponny detailed in an HN thread on Shopify partner governance, the Partner Governance team identified the app as offering external billing and not using the Billing API for all payments. This case serves as a warning for founders building on top of third-party ecosystems. Relying on an external billing system, even if it is technically superior, can lead to sudden account termination if it violates platform terms of service. The cost of "compliance" here is not just the 0.7% fee, but the 20% cut taken by the platform, making the choice of billing infrastructure a strategic regulatory decision rather than just a technical one.

When Stripe Billing Is the Superior Choice

Despite the 0.7% shadow tax, Stripe Billing remains the rational choice for many early-stage SaaS founders. If your product relies on a simple per-seat or per-tier pricing model, the operational overhead of maintaining a custom billing engine or integrating a third-party tool often outweighs the fee savings. For teams with limited engineering bandwidth, the "all-in-one" convenience of Stripe Billing allows founders to focus on product-market fit rather than revenue infrastructure.

As u/vkou noted in an HN thread on Stripe Billing value, being a payment processor is not easy; if it were, nobody would need middle-men like Stripe. For a young SaaS, the cost of a potential billing bug—such as failed invoices or incorrect credit notes—is significantly higher than a 0.7% fee. Founders should only migrate off Stripe Billing when their internal engineering team has the capacity to build and maintain a billing abstraction that is more reliable than the managed incumbent.

Architectural Trade-offs in Billing Abstractions

One HN discussion on Stripe Billing implementation surfaced a consistent pattern: the code itself is simple, but the workflow is the bottleneck. Managing webhooks, customer metadata, and invoice grace periods requires a robust backend architecture that Stripe’s managed service simplifies but also obscures.

As u/tnolet wrote in an HN thread on Stripe Billing webhooks, the actual code is not the problem; the problem is the whole workflow and how it interacts with business backend processes. Founders are increasingly adopting a "billing abstraction" layer. This involves keeping Stripe for the payment processing (where reliability is paramount) but moving the usage aggregation and invoice calculation to a separate system like Paigo or an internal service. This approach ensures that if the billing logic needs to change, the entire payment processor does not need to be swapped out.

Audit Your Billing Stack in Two Hours

If your SaaS is currently scaling, perform this audit to determine if you are overpaying for billing convenience.

1. Calculate Effective Fee Rate: In your Stripe dashboard, extract the total transaction fees and the total billing fees (the 0.7% volume fee) for the last three months. Divide this by total processed volume. If your effective fee exceeds 1.5% of total volume, you are paying a premium for managed billing.
2. Map Usage Complexity: Identify if your billing model is "per-seat" or "per-usage." If it is per-seat, the convenience of Stripe Billing is likely worth the 0.7% fee. If you are tracking API calls or compute time, the 0.7% fee is a drag on your margins.
3. Evaluate Migration Complexity: For usage-based models, investigate the cost of moving to an open-source engine. Check your current webhook volume; if your billing logic requires complex credit notes and negotiated terms, the engineering cost of self-hosting a billing engine may be justified by the long-term savings on the 0.7% volume tax.

Where these threads come from

This analysis draws on eight HN threads that detail the evolution of billing infrastructure from 2019 to 2026. Threads were surfaced via Discury's cross-subreddit monitoring, which helps identify shifts in SaaS operational costs.

discury.io