A guide to evaluating a billing system, part 1

Billing systems fall into the class of tools where, as an engineer, it’s effectively impossible to test every future situation you’ll be in as your company’s pricing changes. In fact, most systems only give you the flexibility to take a narrow, predefined set of actions. It's not feasible to test every single mutation in all situations during an evaluation, so you might discover undesirable restrictions only after you've already committed to using the system.

Broadly speaking, most systems give you a way to subscribe to a set of products — sometimes called a plan. However, the mechanics that underlie this model can be very different.

Are the primitives flexible enough?

In a fixed bundles model, a customer subscribes to a plan (e.g. “Gold”) which consists of a fixed set of prices. Systems like Recurly and Chargebee work this way, where customers can upgrade/downgrade between plans wholesale.

In a phase-based model, plans typically don’t exist. At any given time, a customer is subscribed to a set of assembled products — e.g. “Compute @ $5/unit and Storage @ $10/unit”. Changing the set of subscribed products transitions the customer to a new phase, potentially with the additional or fewer prices. This is how Stripe Billing’s subscription schedule operates.

In a model that supports the true flexibility of prices, a customer’s current subscription is determined by a set of active prices. Each price can be added or removed individually on demand. In this modeling, plans may still exist as both a shortcut to add a set of prices to a subscription as well as meaningful metadata to provide better subscription semantics. This is how a modern billing system like Orb works.

A key area that often best highlights a system’s limitations is how it handles changes to an active subscription; this is where you’ll uncover how brittle most systems are and either force you to make disruptive invoicing changes visible to your end customer, or result in billing incorrect amounts.

Example 1: Simple add-ons

Especially when it comes to usage-based pricing, even the simplest changes can require well-thought-through primitives to accomplish. Imagine you're a file storage company charging $1 for each distinct file downloaded in the month. You offer fast download speeds as an add-on, which comes with a prorated $10 monthly charge.

Suppose you have a customer who's downloading the same 2 files every day, so, at the end of the month, they expect to be charged $2 for their distinct files downloaded. If they want to enable fast downloads in the middle of the month, most systems will surprisingly not let you model this correctly:

• Systems that only support fixed bundles will require that you model a “Basic” plan and a “Pro” plan (the latter with a base monthly fee, and both with a $1/unit usage fee). The action you’ll use to enable the fast downloads feature is an upgrade from Basic → Pro, but you’ll reset the billing period at the point of upgrade and charge separately for file usage on Basic and Pro ($2 each, which would be wrong).
• Systems that support phases will give you the flexibility to add on the download fee instead of creating an entirely new ‘Pro’ plan by creating a new phase that includes both. However, the same problem persists — at the point you change phases, you’ll issue an incorrect invoice for the accrued usage of slow downloads.

Orb, which is flexible enough to treat each price separately, enables you to add the ‘Fast download price’ without splitting the billing period for ‘Distinct files downloaded’. The only invoice that’s issued at the point of enabling fast downloads is for the prorated additional fee, and the file charges are left undisturbed until the end of the month.

Example 2: Included allocations

It’s common for companies to provide an included allocation of usage alongside a base fee. For example, suppose your company sells a generative AI API product. For platform access to the dashboard, you charge $100k/year, and you currently offer two options for API access:

• Starter: At the end of the month, you pay $5,000 for 50K included calls and any additional API calls at $0.05.
• Pro: At the end of the month, you pay $10,000 for 200K included calls and any additional API calls at $0.03.

Suppose a user starts on Starter and mid-month decides based on their already-incurred calls this month that it would be better for them to switch to Pro. Switching to Pro should simply reflect the new allocation for their month, and they should be charged $10K instead of $5k on the upcoming invoice. In order to make sure that switching to Pro does not provide them with an extra 200K call allocation, the system needs to backdate the change and reconsider existing month-to-date usage at the new price.

Plan and phase-based billing systems will typically either fail to let you backdate the change at all, or only provide mechanisms to backdate the action as a ‘plan change’ which will involve prorating and invoicing for the annual platform access fee. This is a confusing experience for your end-user, who hasn’t changed anything about the annual fee.

Orb’s abstractions allow for significantly more flexibility and allow you to change the usage-based API calls price as of the beginning of the month, providing the right behavior out of the box. The remaining allocation and/or overages are automatically recalculated based on existing usage events and the platform fee is left completely unaffected.

Example 3: Contract ramps

Say you’re a financial services company with an established set of plans customers can choose from, and you’re releasing a new product you’d like to support as an add-on. To any subscriber that opts into the product, you’d like to extend a promotion for the first 2 months at a reduced rate, followed by the regular rate afterward.

Depending on the primitives your billing system supports, this seemingly innocuous behavior can be challenging:

• For billing systems built on the plan concept only, you’d need to model the price increase as a new plan. Not only can this get extremely cumbersome, but it’s also semantically not accurate to represent this as a change in the user’s plan — this behavior is markedly different than a regular upgrade or downgrade.
• For systems that operate on phases like Stripe Billing, it’s possible to schedule a two-month out change, but this requires that you re-specify the entirety of the current prices as part of your scheduled phase. This is both a poor developer experience and can make it hard for business and data teams to understand what’s happening: after all, it’s not that the whole collection of prices is changing, but rather a specific price point that transitions after 2 months.

When defining a subscription’s plan, Orb allows you to stage ‘phases’ – preset periods of time with different pricing terms– to represent your contract ramp. Since prices on an active subscription can be modified at any time, phases can be moved in time or created after the subscription is already active. This allows Orb users the fine grained control to immediately add the new product at the reduced rate without issuing any unrelated invoices, and schedule the future pricing change for only the additional product in 2 months.

Conclusion

When selecting a billing system for your business, it's crucial to assess not only how well-designed and flexible their basic pricing models are but also their ability to configure changes, add-ons, and complex pricing structures. The right billing system should empower you to implement your pricing strategies seamlessly, without the need for workarounds, compromises, or, at worst - the inability to implement them at all.