TL;DR (June 2026): Stripe Billing's fee is 0.7% of billing volume on the pay-as-you-go plan, charged on top of payment processing (2.9% + $0.30 on cards), and, the part that surprises everyone, it applies to billing transactions processed on and off Stripe. One-off invoices add 0.4% per paid invoice. The fee buys real machinery: recurring subscriptions, usage-based metering with 100 million events a month included, Smart Retries, dunning, the customer portal, quotes, and multi-phase schedules. Annual pay-monthly plans cut the marginal rate to 0.67% with tier savings up to ~18%. At $10K MRR the fee is lunch money; at $1M MRR it is $84,000 a year and the loudest line item nobody budgeted. A 118-upvote r/SaaS thread this month ("Stripe's billing fees, not the CC fees, are getting out of hand") says where founder sentiment is. Here is the anatomy, the breakeven math, and the four exits.
Every SaaS founder knows the 2.9%. Almost nobody prices in the second percentage, the one attached to Stripe Billing rather than Stripe Payments, until it shows up at scale. This month's r/SaaS thread complaining that the billing fees "are getting out of hand" (118 points, 79 comments) is the recurring ritual: a company grows into the fee, computes what it now costs annually, and experiences sticker shock on a service it adopted when the percentage rounded to zero. The fee has not changed. The volume did. This piece is the arithmetic that should have been done at adoption time, done properly, in both directions, because the honest answer is that 0.7% is simultaneously one of the best deals in SaaS infrastructure and one of the worst, depending entirely on numbers you can compute in ten minutes.
The fee stack, precisely
| Layer | Fee | Applies to |
|---|---|---|
| Stripe Payments | 2.9% + $0.30 (cards, US baseline) | Each transaction processed on Stripe rails |
| Stripe Billing (pay-as-you-go) | 0.7% of billing volume | Recurring billing volume, on and off Stripe, excluding one-off invoices |
| Stripe Billing (pay-monthly, annual contract) | Tiered flat monthly + 0.67% above tier volume | Same scope; advertised savings ~11-18% by tier, custom above the top tier |
| Stripe Invoicing | 0.4% per paid invoice | One-off invoices |
Three details in that table do the surprising:
- "On and off Stripe." The Billing fee is for the subscription machinery, not the payment rails. If a customer pays by wire, ACH through another processor, or anything else while their subscription lives in Stripe Billing, the 0.7% still applies. Teams discover this when they land their first invoice-paid enterprise customer and the billing fee arrives anyway.
- It is a revenue tax, not a margin tax. 0.7% of billing volume is indifferent to your gross margin. A 90%-margin SaaS barely notices; an AI product reselling compute at 30% margin is paying 2.3% of its gross profit for billing machinery before a single engineer or GPU is paid.
- It stacks. Card-paying subscription revenue carries 2.9% + $0.30 + 0.7% before taxes and disputes. On a $29/month plan that is roughly 4.6% of the sticker gone to the payment-and-billing stack alone.
What the 0.7% actually buys
The fee is not rent on an API key, and pretending otherwise produces bad decisions. Pay-as-you-go Billing includes recurring subscription management, usage-based billing with 100 million meter events a month, Smart Retries and recovery automations, automatic payment reminders and dunning, the hosted customer portal, invoice reconciliation, quotes, and multi-phase subscription schedules. Recovered involuntary churn alone can plausibly pay the whole fee at typical SaaS churn profiles: dunning and retry machinery is boring exactly until it is recovering whole percentage points of revenue you would otherwise write off. Anyone running the replace-it-with-cron-jobs calculation has to price rebuilding all of that, which is the honest buy-versus-build exercise, not just swapping an API.
The ceiling matters too: Stripe Billing's metering tops out around 1,000 events per second per account, with 100M events a month included and sales conversations beyond it. For classic seat-and-tier SaaS that is effectively infinite. For AI products metering per token or per request, it is not, and that gap is precisely why Stripe paid a reported $1 billion for Metronome, whose pipeline was built for the 100,000-events-per-second class of customer. We covered what that acquisition means for buyers; the short version is that Stripe itself has conceded the native meter was not built for AI-scale usage billing.
The breakeven math, worked
- $10K MRR: the fee is $70/month. Any alternative that costs engineering time loses. This is the regime where 0.7% is the best deal in infrastructure: a full billing department for the price of two SaaS seats.
- $100K MRR: $700/month, $8,400/year. Comparable to one solid SaaS contract. Flat-fee billing vendors and the annual pay-monthly tiers (marginal 0.67%, advertised savings up to ~18%) start to be worth a conversation, but switching costs still dominate.
- $1M MRR: $7,000/month, $84,000/year, roughly an engineer. This is where the r/SaaS threads get written. Percentage pricing means your billing vendor got a 10x raise for the same service while you did the work of growing 10x.
- $5M+ MRR: $420K+/year at list. Nobody should be on list pricing here; this is custom-contract territory, and the negotiating leverage is the credible ability to leave.
The structural point: percentage-of-revenue pricing for a fixed-cost service diverges from value as you scale. The billing machinery serving a $5M-MRR company is not 500x the machinery serving a $10K-MRR one. Stripe knows this, which is why the tiers, the 0.67% marginal rate, and custom pricing exist. The fee schedule is, in effect, a segmentation engine: the convenient default for small volume, a negotiation for everyone who graduates.
The four exits, ranked by disruption
- Negotiate (do this first). Move to an annual pay-monthly tier or a custom contract. The advertised tier savings run 11-18% and custom goes further. The prerequisite for a good outcome is data: your billing volume, its trajectory, and a costed alternative. A negotiation without a credible exit is a request.
- Unbundle the meter from the biller. The highest-leverage architectural move, and the one most teams skip. Keep Stripe Billing for what it is great at (subscriptions, dunning, the portal, compliance surface) but own your usage pipeline: meter events in your own layer, aggregate, then push rated quantities into Billing. This shrinks the surface you depend on, keeps the usage data (your pricing experiments, your unit economics, your cost-per-task analytics) in a system you control, and makes exits 3 and 4 possible later without a data migration. It is the pattern we detailed in complementing Stripe with usage metering.
- Replace the billing layer, keep the rails. Open-source billing (Lago, Kill Bill) or flat-fee vendors on top of Stripe Payments. You keep the 2.9% + $0.30 and drop the 0.7% for a flat cost that does not scale with revenue. The price is real engineering ownership: upgrades, edge cases, tax integration, dunning quality. Lago's own positioning ("why Stripe paid $1B for Metronome instead of fixing Billing") tells you both that the alternative exists and that it markets against exactly this fee.
- Build. Almost always wrong below eight figures of ARR, per the scars we have documented. The exception is products whose billing IS the product, or whose event volume and pricing complexity exceed what any vendor meters sanely.
The decision rule
Price your billing stack the way you price any vendor: dollars per year against the cost of the best alternative, re-evaluated at every revenue doubling. Under $100K MRR, pay the 0.7% and spend your attention elsewhere. Between $100K and $1M, negotiate the rate and unbundle the meter so your exit option stays live. Above $1M, treat list-price percentage billing as a choice you are actively making every quarter, because $84K/year buys a lot of alternative. And whatever layer you choose for invoicing, never let the billing vendor be the only system that knows your usage: the meter is where pricing power, unit economics, and switching leverage all live. Vendors understand this, which is why metering is increasingly bundled. Buyers should understand it for the same reason.
The honest take
The r/SaaS anger is half right. Stripe Billing at 0.7% is a genuinely excellent product at small scale and a structurally overpriced one at large scale, and the line between those regimes is crossed silently, by growth, while nobody is watching the fee schedule. The half that is wrong is treating the fee as pure rent: dunning, retries, metering, portals, and quotes are real software with real alternatives that cost real money or real engineers. The failure is not paying 0.7%. The failure is still paying it by default at a volume where you would never agree to it fresh, with your usage data locked inside the thing you would need to leave. Do the ten-minute math at every doubling, keep the meter yours, and the fee becomes what it should have been all along: a deliberate purchase, not a tax.