DEV Community: Arnon Shimoni

Why we treat credits and wallets as first-class billing primitives

Arnon Shimoni — Sat, 16 May 2026 21:09:02 +0000

tl;dr: Most billing systems model a credit wallet as a prepaid cash balance. That works at day zero. It breaks the moment your product has multiple types of credits with different per-unit costs, different margins, and different rate cards sitting between your token layer and your customer-facing price. Our customer Reson8 needed multiple wallets, structured around a rate card layer instead of one prepaid counter.

Lots and lots of billing systems model credits as prepaid cash. Pay $100, get $100 of credit. Burn the credit, the balance goes down. That's because it's often treated as "just an engineering thing" where it's a fancy counter.

The model is clean until your product has more than one thing customers buy credits for.

Why we'd rather hold credits than money

There's a line we come back to internally:

I'd rather have credits in a wallet than money, because money I have to give back. Credits I can expire.

A money wallet creates a liability. Whatever your customer deposits, you owe it back if they don't spend it. Credits work on your terms: when they expire, what they cover, under what conditions they're valid. The obligation is yours to design.

Not great for customers necessarily, but great for businesses running with AI.

A wallet targeting a single product category is what tax law calls single-purpose: intended use is known at purchase, so VAT is calculated when the funds go in. A general-purpose wallet, where a customer might spend across your product, is multiple-purpose: intended use is unknown at purchase, so VAT is calculated when they actually use it. Credits are a third category. You're selling a product (100 credits for $90), VAT applies at purchase, and the credit has its own exchange mechanics entirely separate from currency.

So if you have three wallet types, you get three different VAT treatments and three different points of revenue recognition.

If you model them as one thing and finance finds out later, and won't be happy with you.

Why single wallets aren't right

The single-wallet model assumes interchangability. All credits are equal. One credit buys one unit of anything in the product.

That assumption is kinda true for simple products but not for modern AI stuff where the cost of delivering one unit varies across workloads. A minute of transcription on a custom-trained domain model costs more to deliver than a minute of batch generic transcription. If you change languages it becomes even clearer, because the underlying token countss are not the same.

When those two workloads draw from the same credit pool, the billing system can't enforce that difference. That means customer's credits become fungible across products that aren't and the margin doesn't match what was invoiced.

That's a data model problem!

What Reson8 needed

Reson8 builds hyper-customizable speech recognition for European languages: real-time, domain-adaptive, running on EU GPUs with no audio retention. They bill by the minute across multiple workload types. Standard transcription. Custom-domain models adapted on up to 1M tokens of customer context with real-time processing versus batch - and each has a different cost basis.

The moment a customer at Reson8 pre-purchases minutes, the question becomes: which kind? Standard-transcription minutes and custom-domain real-time minutes are different products. You can't let customers use one pool for the other: the product doesn't allow it, and the margin profile doesn't support it.

What companies like Reson8, ElevenLabs, Wispr need is at least three distinct rating systems, that translate to wallet types: one for standard minutes, one for custom-domain minutes, and one that handles real-time processing overages as a metered charge when the pre-purchased pool runs empty.

In theory, each can have its own top-up schedule, expiry rules, and invoicing behavior.

A single prepaid balance doesn't model that. It guesses at it at best.

The token layer is why

Speech AI adds a dimension most billing systems weren't built around. The model thinks in tokens. The customer thinks in minutes. Contracts denominate in credits. Finance works in dollars (or Euros).

Each link is a rate:

tokens → minutes → credits → dollar

A minute of real-time transcription in a custom-adapted model on a dedicated EU cluster consumes more tokens than a standard batch job on a generic model. The conversion factor varies by workload, by model version, by language pack, by the level of domain adaptation the customer has configured.

Most billing systems let you set a price per event, or a price per unit of consumption. What they don't support is a rate card layer sitting between the metering layer and the wallet layer. A rule that says: one meter event tagged workload: custom-realtime burns 3 credits from wallet B, while one meter event tagged workload: standard-batch burns 1 credit from wallet A.

Remember I said engineers see it as a counter? That's not how counters work.

When that rate card lives in application code rather than billing configuration, it's invisible to finance and re-coded every time the cost model changes. Which in AI, is quote often.

Why the rate card has to be in the billing layer

Lots of speech vendors also have custom model adaptation as a product in its own right: a one-time charge to adapt the model on a customer's data, then a recurring credit pool to use it. The initial adaptation and the ongoing credit wallet are related but distinct events.

The whole revenue stack has to handle both on the same invoice and recognize revenue at the right moment for each.

You could call this hybrid, where a one-time charge triggers a wallet provisioning event, the wallet burns down as the customer runs workloads, it auto-tops-up on a schedule or on demand, and overages switch to real-time metering when the pool hits zero.

For that to work, the wallet has to carry more than just a counter, but some extra metadata: which plan provisioned it, which meters feed into it, which rate card converts events into credit deductions. A counter doesn't do that.

The Stripe method (and lots of other vendors) have gift-cards or "balances" given to a customer, but they're not separate objects - you can't spin them up and move them around. Connecting them requires orchestration code you write and maintain. Lago's credit primitives don't compose naturally with multi-wallet, multi-rate-card configurations and if you're building on top of them - you need your own custom ogic that reimplements the billing layer on top of the billing layer.

In Solvimon, Wallets are a first-class primitive. Multiple wallet types per customer, each tied to a specific meter and a rate card, with configurable top-up and expiry rules. The rate card lives in configuration. Finance can see it, and the billing system enforces it.

What changes for revenue recognition

Good wallet modeling cleans up revenue recognition.

A customer pre-purchasing 10,000 standard minutes creates a deferred revenue liability. Each minute consumed triggers a recognition event against the right wallet. When the pool empties and the customer tips into metered overages, billing switches from credit burn to real-time usage. Finance sees one invoice, one ledger. The wallet's depletion is the revenue recognition schedule.

During billing calculation, credits are reserved against pending invoices, then deducted only when the invoice goes final. Available balance is real balance minus reservations. That gap between reservation and deduction prevents customers from overspending mid-cycle, and makes the recognition schedule traceable without a spreadsheet.

For Reson8, that matters. EU customers care about data handling and contract structure. An invoice that reflects custom-domain usage, standard usage, and real-time overages as distinct line items, each traced to its wallet and rate card, holds up in procurement, in audit, and in the customer relationship. That's not my favourite thing to have to design around, but healthcare and financial services procurement teams care quite a lot about this.

The big decision/question behind credit pricing you need to make

Credits carry a pricing decision inside them: what value to attach to each unit. The structural question is whether your billing system can model the relationships between your metering layer, your credit pools, and your revenue recognition without engineers maintaining the translation.

For AI companies running multiple workloads with different cost bases, that requires multiple wallets and a rate card layer that understands what each pool represents.

Frequently Asked Questions

Why would a company prefer credits over a money wallet?

A money wallet creates a financial liability: you owe the deposited amount back if the customer doesn't spend it. Credits are a product sale: the customer buys a defined unit with defined terms, including when those credits expire. That distinction affects your balance sheet, your VAT treatment, and how you recognize revenue. For many AI companies, credits are preferable precisely because you set the expiry terms rather than holding an open-ended obligation.

What is the difference between a credit wallet and a prepaid balance?

A prepaid balance is a single pool of value denominated in currency. A credit wallet is a typed pool denominated in a product-specific unit (minutes, tokens, API calls) with a rate card defining how it converts to currency and a meter defining what consumes it. For simple products, they're equivalent. For products with multiple workload types, only the wallet model holds up.

Why would an AI company need multiple credit wallets for the same customer?

When a product has multiple distinct workloads with different unit costs and different margins, a single pool treats all credit consumption as equivalent regardless of delivery cost. Multiple wallets enforce the boundary. Each wallet is tied to the workloads it covers, with its own rate card and top-up behavior.

What is a rate card in AI billing?

A rate card is a configuration layer that defines how a metering event converts into a credit deduction. For a speech AI company, this might be: one minute of real-time custom-domain transcription = 3 credits from the custom wallet. The rate card sits between the metering layer (which counts consumption) and the wallet layer (which tracks the balance).

When rate cards live in application code, they're invisible to finance and hard to update - which is why you should keep them in a billing system.

How does token-to-credit conversion work in practice?

The model layer consumes tokens. The product layer exposes a customer-facing unit (e.g., minutes). The billing layer converts that unit into credits at a rate defined by the rate card. A minute of transcription in a given model configuration costs a known number of tokens to produce. When the model changes and the per-minute token cost changes, the rate card updates in configuration.

Can Stripe Billing handle multiple credit wallet types?

Stripe Billing supports basic combinations of subscription billing and metered usage, and has a credit grants, but not tied to wallets. Getting them to interact, especially across multiple credit types with different rate cards, requires custom orchestration code. Most teams building multi-workload AI products end up maintaining that orchestration layer themselves.

How does Solvimon model credit wallets?

Solvimon treats Wallets as a first-class primitive: multiple wallet types per customer, each associated with a specific meter and a rate card, each with configurable top-up and expiry rules.

The rate card layer handles the conversion between consumption units and credit deductions. Revenue recognition is calculated against wallet events. Wallet configuration lives in Solvimon rather than in application code.

The hard part of usage-based billing isn't the metering

Arnon Shimoni — Thu, 14 May 2026 08:13:17 +0000

Every AI company I talk to is running two pricing motions at once:

A subscription for platform access
+ consumption charges on top.

Sometimes a third if we consider the prepaid credits…

The single-bill view is the easy part. The hard part is what's underneath with three different rating engines arguing about who owns the customer's invoice this month.

This is a piece about what usage-based billing actually requires from your stack, the pricing models people are running, and where the comparison between Stripe Billing + Metronome and Solvimon actually stops being relevant (hint: not cost)

How usage-based billing works

There are typically three components, working in sequence in UBB:

Event collection. Your product emits an event for every billable action (an API call, a token consumed, a task completed). High volume, no data loss, audit trail, the whole shebang.
Metering and aggregation. Raw events get aggregated into billable quantities, per customer, per product line, per billing period, you name it.
Rating and invoicing. Aggregated quantities get multiplied against the applicable rate to produce an invoice.

The hard part is in step 3 because of the complexities of "actioning" the math.

Two customers can consume identical volume and owe different amounts because they're on different plans, different commitment tiers, or have a custom rate the AE negotiated at 2am on the contract close. The billing engine has to hold all of that in its head simultaneously, and apply the right logic per customer per cycle.

You may think that's a minor thing but that's most of the work.

The pricing models people are running

Here's what I see across our customers at Solvimon:

Pure consumption. Pay per unit, fixed rate, no minimum. Common in dev-facing AI APIs (e.g., the early OpenAI API). Volume varies wildly, customers refuse to commit, you eat the variance.

Tiered. Per-unit rate decreases with volume, in two types:

Style	What it means
Volume	Final tier rate applies to all units
Graduated	Each tier's rate applies only to units in that band

You need to support one or both, and you need to do it consistently. (The number of pricing pages I've seen that claim "graduated" and silently rate as "volume"... well.)

Committed consumption with overage. Customer commits to a minimum spend or volume at a negotiated rate. Usage inside the commit bills at that rate. Usage above bills at a higher overage rate. This is the dominant structure for enterprise AI contracts right now. Predictable revenue for the vendor, predictable cost for the buyer, until the commit doesn't cover the year-end traffic spike. Then it gets interesting.

Credit-based. Customer prepays into a balance. Usage draws it down and new credits get bought any time and all the time. You then have to decide:

Do credits expire? At period end, never, or with a max balance roll-over?
How is breakage (unused expired credits) recognized?
How fresh does the balance need to look in the customer's UI? (Real-time, if you want to keep enterprise customers.)
If one balance spans multiple products, who tracks which product drew which credits?

Again, like before - these aren't things you can just guess or decide because they're the architecture you'll be stuck with for eons.

Hybrid. The catch-all for recurring base fee plus usage on top, consolidated onto a single invoice. Most enterprise B2B AI deals are shaped this way (e.g., a $50K/quarter platform fee plus tokens-consumed overage). The system runs subscription logic and consumption metering and then reconciles them.

What the billing infrastructure actually has to do

The list of things is long but the bar to reach, meaning the quality you have to live up to is surprisingly hard to get right:

Event ingestion from a warehouse (Snowflake, BigQuery, Redshift) or directly via API. AI products at scale are doing millions of events a day. The pipeline has to handle that without dropping events.
Real-time metering. Enterprise customers expect to watch usage accumulate in their dashboard, not wait for the invoice. For credit-based products this is non-negotiable.
A rating engine that holds custom terms. Per-customer overrides, ramp schedules, mid-cycle plan changes, currency conversion, recalculation when terms change. Pricing exceptions stay attached to subscriptions as structured data, not as PDF amendments stuffed in Salesforce.
Subscription and contract management at the structured-data level. Bulk migrations, i.e., moving hundreds of customers from one plan version to another while preserving per-customer custom terms, is a routine operation in mature systems. In immature ones it's a JIRA epic.
Multi-entity, multi-currency. Different legal entities, different currencies, different tax jurisdictions, different invoice formats, intercompany reconciliation. Becomes a hard requirement the day you sign a customer in a country that wasn't on the roadmap.
Tax. My favorite topic - because you can either go native, or via Avalara, Anrok, Sphere, etc. Usage-based tax is harder than subscription tax because the taxable amount changes every invoice.
Revenue recognition. My second favorite because under ASC 606 / IFRS 15, you recognize revenue as performance obligations are satisfied. For consumption: as usage occurs. For credits: deferred until consumed. Your billing system needs to feed period actuals, deferred revenue balances, and contract modification records into the finance team's stack in a form they can actually use. This is where most billing-system replacements get triggered.

Stripe Billing + Metronome vs purpose built system like Solvimon

Series B AI companies scaling internationally usually look at two architectures:

Stripe Billing + Metronome. Stripe runs subscriptions, invoicing, and payment collection. Metronome sits above it as the metering, rating, and event processing layer. You're integrating two systems and owning the seams.
Solvimon. Catalog, Metering, Subscriptions, Wallets, Entitlements, Invoicing, Revenue, Workflows in one system. Solvimon connects to Adyen, Stripe, Checkout.com as payment gateways rather than replacing them. (Built by the team that ran billing at Adyen at over €1T in annual payment volume.)

The cost question is the wrong question to lead with because it doesn't matter as much as the architecture:

Capability	Stripe Billing + Metronome	Purpose built system like Solvimon
Usage metering	Metronome (separate system)	Native
Pricing model configuration	Code/API for non-trivial cases	UI, no engineering required
Tax handling	Third-party required	Native but third-party also available
Revenue recognition	Stripe RevRec add-on or separate tool	Period actuals into the finance team's stack
Multi-entity	Engineering work	Native
Payment gateways	Stripe	Adyen, Stripe, Checkout.com
Bulk plan migrations	Engineering work	UI-based bulk operations
Best suited for	Engineering-led teams already on Stripe	Finance and RevOps-led teams, complex enterprise contracts

The Stripe + Metronome stack works when you have engineering capacity to own the seam between the two systems and your pricing changes infrequently. Solvimon makes more sense when finance or RevOps wants to own pricing configuration directly, when enterprise custom terms are accumulating faster than you can wrangle them in code, and when you want pricing iteration to move at the speed of a product manager rather than an engineering sprint.

These are different bets. They're not better-or-worse bets.

What to evaluate when choosing a billing architecture

Forget feature lists. Five questions cut through:

Configuration ownership. Can finance or RevOps change a pricing model directly, or does every change require an engineering ticket? This determines how fast you can respond to a competitor or to model-cost shifts.
Mid-cycle changes. A customer upgrades in week two. How does the system prorate? The right answer is automatic, auditable, consistent across customers.
Credit architecture. Expiration rules, breakage handling, balance freshness, multi-product allocation. Hard to change post-launch.
Bulk operations. Moving customers across plan versions while preserving per-customer custom terms. How the platform handles this tells you whether it was designed for enterprise scale or shipped with the assumption that you'd never need it.
The data pipeline to your finance stack. Where do usage events enter, what's the lag from usage to billing record, and what does reconciliation look like when event counts don't match invoice amounts? This is where most billing-system errors originate. Ask to see the data model before you commit.

Best subscription billing software for SaaS in 2026: A decision guide

Arnon Shimoni — Mon, 11 May 2026 14:58:41 +0000

tl;dr:

There is no single best subscription billing software for SaaS in 2026, and there never was before that. There is however, one that is best for your decision. Eight platforms compete in this market and each one wins a specific buyer.

Pure subscription lifecycle: Chargebee, Maxio, plus Recurly if you're B2C
Pure usage: Metronome
Hybrid pricing (seats, usage, credits, outcomes): Solvimon
Merchant of record for global tax: Paddle
Already deep in Stripe: Stripe Billing
Large enterprise multi-product, where money is no object: Zuora

I'll walk you through five questions that decide your branch, and the trade-offs that matter for each platform.

Why this question is harder in 2026

The category split that mattered in 2020, subscription billing versus usage metering, has collapsed. Most modern SaaS companies sell hybrid pricing now. Seats for the dashboard. Usage for the API. Credits for the AI features. Sometimes outcomes for the agent runs.

The platforms that grew up serving one of those models are scrambling to add the others. The ones built native to hybrid have a structural lead. (And the buyers who picked the wrong tool in 2022 are migrating in 2026.)

The decision today is not "which tool has more features." It is "which tool fits the pricing I'll be selling in two years, in the geographies I'll be selling in, with the engineering team I'll have." That's the question this guide answers.

The 5 questions that decide the billing choice

Before evaluating vendors, think about these five questions:

1. What's your pricing model? Pure subscription (seats, plans, tiers), pure usage (API calls, tokens, events), or hybrid (some combination, including credits and outcomes). What is your FUTURE pricing model - is it going to always remain the same?

2. What's your buyer mix? Pure PLG self-serve, pure sales-led contracts, or both. Hybrid GTM is now the default for B2B SaaS over $5M ARR.

3. What's your geographic scope? Single entity, single currency. Or multi-entity, multi-currency, with VAT and GST obligations across regions.

4. What's your tax posture? You handle compliance yourself with a tax engine. Or you want a merchant of record to take it off your plate (and a percentage of revenue with it).

5. What's your engineering posture? Comfortable configuring billing through a vendor dashboard. Or you want billing as code, versioned, scriptable, integrated into CI/CD.

The answers map cleanly to one of the six decision branches below.

The decision tree

If you sell pure subscriptions: Chargebee, Recurly, or Maxio

These three platforms grew up serving pure-subscription B2B SaaS. They handle plan lifecycle, prorations, dunning, and revenue recognition well. They are weaker on usage-based pricing and hybrid models.

Chargebee

The lifecycle leader for mid-market subscription SaaS. Strong on trial-to-paid conversion, plan upgrades and downgrades, multi-currency, and tax. Used by finance and RevOps teams that want defined workflows around billing.

Where it wins: established mid-market SaaS with stable subscription models that change pricing once or twice a year, not weekly.

Where it doesn't: pure usage-based pricing, AI metering, or hybrid models that mix seats with consumption. Chargebee has added usage features over the past two years, but the core architecture is subscription-first.

Pricing: contact sales.

Recurly

The dunning specialist. Recurly's involuntary churn reduction is its defining feature, with smart retry logic that reduces failed-payment churn meaningfully for subscription businesses. ASC 606 revenue recognition is built in. Accounting integrations are deep.

Where it wins: subscription businesses where involuntary churn is the primary revenue leakage problem.

Where it doesn't: anything outside the subscription and dunning core. Limited usage support, no CPQ, narrower feature surface than full-stack platforms.

Pricing: contact sales.

Maxio

Born from the SaaSOptics and Chargify merger. Maxio is the finance-led choice. GAAP-compliant revenue recognition, deep ARR and NRR reporting, churn cohort analysis. CFOs like it because the reporting is audit-ready out of the box.

Where it wins: finance-led B2B SaaS with strict revenue recognition needs and ARR / NRR reporting requirements.

Where it doesn't: API-first or developer-led teams. Maxio is a finance tool that does billing, not a billing platform that does finance.

Pricing: contact sales.

If you sell pure usage or consumption pricing: Metronome

Metronome is purpose-built for consumption billing. Real-time event ingestion, complex rating logic, high-fidelity metering. The customer base skews developer-first: API companies, infra platforms, AI inference providers.

Where it wins: pure usage-based companies that need a metering engine more than a subscription manager.

Where it doesn't: hybrid pricing with subscriptions, CPQ, or multi-entity invoicing. Metronome's scope is narrower than full-stack platforms.

Pricing: contact sales.

If you sell (or plan to sell) hybrid pricing (seats, usage, credits, outcomes): Solvimon

Solvimon was built native to hybrid pricing where seats and usage and credits and outcomes coexist in the same ledger, with no orchestration code stitching subsystems together. The primitive vocabulary is explicit: Catalog (the products and prices), Metering (real-time usage ingestion), Wallets (credit pools and rollovers), Subscriptions (recurring lifecycle), Entitlements (what each customer can access), Invoicing (multi-entity, multi-currency), Revenue (recognition and reporting), Workflows (the connective tissue).

Two architectural choices set Solvimon apart from the rest of this list.

PSP-agnostic - Solvimon works with Stripe, Adyen, and Checkout.com. You can switch payment processor without rebuilding billing. Stripe Billing locks you into Stripe. Solvimon doesn't lock you anywhere.
Headless - configuration happens through the dashboard, the CLI, the API, and an MCP server. Pricing changes ship as code, in pull requests, with tests. Engineers don't sit in dashboards. They ship pricing the same way they ship features.

Where it wins: AI-native companies, hybrid pricing, multi-entity global SaaS, teams that want billing as code rather than billing as a dashboard. The "outgrown your first system" buyer, the one who started on Stripe Billing or Chargebee and hit the wall somewhere between $5M and $15M ARR.

Where it doesn't: simple pure-subscription businesses that will never need usage or hybrid. Chargebee or Recurly will get you there with less surface area.

Customer proof: Yapily migrated 700 plans off custom code in 90 days.

Pricing: free up to $1M billed on the Essential plan, then $1,000/month up to €2M billed and 750K events/month. Solvimon for AI is free up to $3M billed, then 0.4%. Growth and Enterprise tiers are custom. [VERIFY against live /pricing page before publishing.]

If you want a merchant of record for global tax: Paddle

Paddle takes the merchant-of-record role. They become the seller of record in your transactions, which means they handle VAT, GST, US sales tax, and the compliance overhead that comes with selling internationally. You give up a percentage of revenue. You get back the time and risk of running tax compliance yourself.

Where it wins: SMB and mid-market SaaS selling internationally, especially self-serve. The buyer who'd rather pay 5% to Paddle than hire a tax compliance team.

Where it doesn't: enterprise contracts, hybrid pricing, custom CPQ, or any scenario where you need control over the customer relationship. The MoR model trades flexibility for compliance simplicity.

Pricing: revenue share. Contact sales for enterprise tiers.

If you're already deep in the Stripe ecosystem: Stripe Billing

Stripe Billing is the path of least resistance for teams already running Stripe Payments at depth. The integration is tight. Developer experience is strong. For simple recurring subscriptions, the time-to-launch is hard to beat.

Where it wins: PLG SaaS with simple subscription plans, already on Stripe, with no immediate need for hybrid pricing or multi-entity billing.

Where it doesn't: PSP optionality (you're locked to Stripe), enterprise contracts, multi-entity global billing, or hybrid pricing at scale. Teams routinely hit the Stripe Billing wall between $5M and $15M ARR and migrate.

Pricing: 0.5% to 0.8% of billing volume depending on plan. [VERIFY current Stripe Billing pricing tiers.]

If you're large enterprise with multi-product complexity: Zuora

Zuora is the enterprise incumbent. 50+ pricing models, deep compliance reporting, customizable discounting, multi-product billing. The platform CFOs at Fortune 500s default to.

Where it wins: large enterprises with complex multi-product billing, deep compliance requirements, and the budget for a multi-quarter implementation with consultants.

Where it doesn't: anything that needs to ship fast. Zuora is a heavy implementation that can take a year to implement. Total cost of ownership is high. Smaller teams will spend more time configuring than selling.

Pricing: contact sales.

Side-by-side comparison

Platform	Pricing model fit	Best for	Pricing
Solvimon	Hybrid: seats, usage, credits, outcomes	AI-native, scaling SaaS, multi-entity, headless monetization	Free to $1M billed, then custom
Chargebee	Subscription	Mid-market B2B SaaS	Contact sales
Zuora	All models, enterprise-grade	Large enterprise multi-product	Contact sales
Recurly	Subscription with strong dunning	Subscription-first SaaS	Contact sales
Maxio	Subscription with finance reporting	Finance-led B2B SaaS	Contact sales
Stripe Billing	Subscription, simple plans	PLG already on Stripe	0.5% to 0.8% of volume
Paddle	Subscription with MoR	Global self-serve SaaS	Revenue share
Metronome	Pure usage / consumption	Developer-first usage businesses	Contact sales

What's changing in 2026?

The reason this list looks different from a 2022 buyers' guide is that the underlying pricing models have changed - and things have become more popular (usage-based pricing) or less popular (seat pricing)

Three years ago, most SaaS companies sold seats. Billing platforms sold subscription lifecycle and the world was happy and tidy.

As of May 2026 the typical B2B SaaS company has three pricing surfaces in production at once. On Solvimon, most customers have five on average. A self-serve plan (seats), an API or AI feature (usage or credits), and a custom enterprise contract (negotiated mix). Companies are rightfully pricing on whichever model fits the surface, not picking one.

That puts pressure on the billing layer because a platform that grew up doing subscriptions has to bolt on usage, while a platform that grew up doing usage has to bolt on subscriptions. The seams show up in the customer experience, the engineering backlog, and the revenue leakage at month-close.

The platforms that win the next decade will be the ones built native to hybrid pricing, with PSP optionality, multi-entity infrastructure, and a configuration model that doesn't require an engineering ticket for every price change. Solvimon's wedge phrase, "billing and payments for companies that have outgrown their first system," names the buyer this market is producing in volume.

If you're picking a platform now, pick for where you'll be in 2028, not where you are today.

How I evaluated these platforms

The criteria that drove this guide:

Pricing model coverage: subscription, usage, credits, outcomes, hybrid combinations
Metering: real-time ingestion, rating logic, event deduplication
CPQ: quote-to-cash, custom contracts, multi-year ramps, tiered discounts
Global capability: multi-entity, multi-currency, VAT and GST tax engines, FX
PSP relationships: locked to one processor, or agnostic
Configuration model: dashboard, API, CLI, code, MCP
Revenue reporting: MRR, ARR, NRR, ASC 606 compliance, deferred revenue
Total cost of ownership: implementation time, engineering lift, pricing
Buyer evidence: G2, Gartner, customer migration patterns

This is not a Gartner Magic Quadrant. There is no single winner. There are six decision branches and eight platforms that win different ones.

FAQs

What is subscription billing software?

Subscription billing software automates recurring invoicing, payment collection, and revenue recognition across the customer lifecycle. Modern platforms also handle usage metering, CPQ, multi-entity invoicing, and hybrid pricing models that combine subscriptions with usage, credits, and outcomes.

What's the difference between subscription billing and usage-based billing?

Subscription billing charges a recurring amount on a defined cycle (monthly, annually). Usage-based billing charges based on consumption events (API calls, tokens, transactions). Hybrid models combine both, often with credits or wallets layered on top. Most modern SaaS uses hybrid in some form.

How is Solvimon different from Stripe Billing?

Stripe Billing is the billing layer of the Stripe payments ecosystem. Solvimon is PSP-agnostic billing infrastructure that works with Adyen, Stripe, or Checkout.com. Stripe Billing is optimized for simple subscription plans on Stripe. Solvimon is optimized for hybrid pricing, multi-entity global billing, and headless monetization.

When do SaaS companies typically migrate from Stripe Billing?

The pattern: companies hit the Stripe Billing wall somewhere between $2M and $15M ARR, usually triggered by one of three needs. Hybrid pricing (adding usage to seats). Multi-entity billing (multiple legal entities or currencies). Or an enterprise contract that Stripe Billing's CPQ can't handle.

What's headless monetization?

Headless monetization is the model where billing is configured the way modern frontends are configured. Through APIs, CLIs, code, and MCP servers, not through dashboards. Pricing changes ship as pull requests, with tests, in CI/CD. Engineers stay in their IDE. Finance still gets the dashboard for reporting. Solvimon is the platform built native to this model.

What's the best free subscription billing software?

The Solvimon Essential plan is free up to $1M billed annually, including 750K events per month and one billing entity. The Solvimon for AI plan extends free usage up to $3M billed.

Which billing platform handles multi-entity global SaaS best?

Solvimon and Zuora handle multi-entity global billing natively. Solvimon ships it from day one with built-in VAT, GST, and FX. Zuora handles it through enterprise configuration with longer implementation cycles. Stripe Billing require ssome stitching for multi-entity at scale.