Tier works by orchestrating the management of your existing
Stripe account, according to a model defined in your
pricing.json configuration, and provides
commands that can be used to manage schedules and report usage.
As everything is mapped into Stripe objects with unobtrusive metadata conventions, you may of course always use features of Stripe as you see fit. This guide will help show how to get the most out of Tier as a single source of truth in your PriceOps architecture.
Defining a Model
pricing.json file, and push it to
Stripe using the
tier push command.
Tier Org IDs vs Stripe Customer IDs
Tier is designed to work with the identifiers that you already have for your customers and features, rather than requiring you to track multiple identifying strings which can get out of sync.
However, when interfacing with Stripe directly (for example, to
collect payment information using
SetupIntent objects), you will need the Stripe customer ID.
You can get this from the
tier whois command,
or at run time using the
whois() method from a Tier
Tier org IDs are always prefixed with
Creating a Customer
tier subscribe command to provide
an org ID and a versioned plan identifier. At run-time, use the
subscribe() method in the Tier SDK.
This creates their Schedule in Stripe, and enables reporting usage of features.
Checking for Feature Entitlement
In order to determine if a customer has access to a given
feature, use the
tier limits command, or the
limits() method on a Tier SDK.
Note that the
used amount may be higher than the
amount! Depending on your circumstances, you may wish to allow
customers to exceed their plan limits, or cut off their access
to a given feature immediately.
Reporting Feature Consumption
When a user consumes some amount of a feature, record the usage
in Stripe using the
tier report command, or
report() method in a Tier SDK.
Note that this should be done using the
feature identifier in
your model. Tier will attach the usage to whichever
object in Stripe corresponds the specific customer's