Schematic enables you to implement usage-based billing models quickly, and enforce any associated limits within your product as your customers reach them using Schematic’s feature management capabilities.
For instance if you have a pay in advance model, when a customer reaches the credit limit, you can prevent them from using more.
While base charges (e.g. a subscription fee) are defined at the plan level, as described here, usage-based billing is defined at the individual entitlement level.
Usage-based billing is a pricing model where customers are charged based on their usage of a particular feature. This model is useful for businesses offering variable or consumption-based products, such as APIs, cloud services, or subscription tiers with metered features.
Schematic supports a number of usage-based models. If the one you care about is missing, please send us a note at hi@schematichq.com.
Charge customers based on their usage of a feature without a preset fee or limit.
This is ideal for event-based features in Schematic such API calls or SMS usage.
Charge customers up front for pre-defined usage.
This is ideal for scenarios where customers prefer buying usage in pre-determined chunks, and is supported for trait-based features in Schematic such as Seats or Projects.
Include some amount of usage for a fixed fee, and then charge customers for any additional usage.
This is ideal for scenarios where many customers will fall into the plan’s quota, but you want to allow (and benefit from) customers with heavy usage.
Volume pricing is a common way to provide discounts for large usage. In volume pricing, usage tiers are defined, and the final price paid is based on the usage tier the customer falls into.
Schematic allows you to define the price of each tier as a fixed amount, a per-unit price, or a combination of the two.
For example. If pricing tiers are defined as follows:
A customer who uses 150 units would be charged $144 ($9 + 150*$0.90). Notice how only the final tier the customer fell into (101-200) determines the price. This can lead to sharp changes in price around usage cutoffs.
Graduated pricing is another way to provide discounts for large usage. In graduated pricing, usage tiers are defined, and the price per unit changes as the customer moves through the tiers. In this model, units used earlier in a billing period often cost more than those used later, leading to a more gradual volume discount. The final blended per-unit price cannot be determined until the end of the billing period.
Schematic allows you to define the price of each tier as a fixed amount, a per-unit price, or a combination of the two.
For example. If pricing tiers are defined as follows:
A customer who uses 150 units would be charged $164 ($10 + 100*$1 + $9 + 50*$0.90). Notice how the first 100 units are charged at $1, while the next 50 units are charged at $0.90.
Because the customer had usage in 2 different tiers, they paid the flat fee price for both tiers. This is typically not the desired behavior, which is why flat fee pricng is not common in graduated pricing models. If you want to include a flat fee, consider adding it to the base plan price, or only including it in the first tier.
Checkout our Credit Burndown Docs.
Schematic supports submitting track events with negative quantities to reduce usage, for use cases such as refunds, corrections, or reversals. Negative quantity events must be submitted using a secret API key — publishable API keys will reject them.
As an alternative to sending negative values for adjustment, usage events can be backdated. If trusted_client_clock is true, clients can set their own value for sent_at. See Backfills and usage corrections.
Include a negative integer for the quantity field in your track event. The quantity must be a non-zero integer (fractional values are not supported).
Negative quantities affect billing differently depending on the pricing model configured for the feature’s entitlement:
For Stripe-integrated billing models (pay as you go, tiered, overage), Stripe enforces that the net usage for a billing period cannot be negative. If negative events would push the period total below zero, the excess adjustment is effectively ignored by Stripe. Plan accordingly when issuing refund events.