(Note that what we call a "plan" is more like what Stripe calls a "subscription" than what Stripe calls a "plan!")Ī good first question to ask about a data model is, "where does the data live?" An API plan is a paid tier of service, billed monthly, that allows a team to use our API calls to create, configure, and use rooms, recordings, and other features.All video call rooms are created under a team subdomain, and multiple users can share access to a team. A team is a subdomain (for example, ).A user is someone with an email address who has created a account.In our world, we have users, teams, and plans. An invoice generated by a subscription (usually) attempts to charge a customer's credit card, and Stripe events/webhooks are created to help you track and respond to pre- and post-payment events.A subscription generates recurring invoices. A subscription is an association between a customer record, and one or more plans.For example, you might have different plans for customers who are paying in different currencies. You can create several different plans for each product. A plan is what you charge for a specific product (how much, and how the amount is calculated).It's useful to think of a product as mapping directly to a line item on an invoice. A product is something that you charge a customer for.A customer record is an account with a unique id, an email address, and (usually) a stored payment method.Stripe customers, products, plans, subscriptions, and invoicesĪlmost all recurring billing tasks, in Stripe's systems, are built on top of the following five top-level abstractions: So we needed to dig in to understand how Stripe's recurring billing features are designed. Or, put a different way, until we have a data model we're confident in, we're just prototyping, not implementing!įor this project, the data model needs to translate between our representation of customers, subscriptions, and settings and those same concepts in Stripe's APIs. If we start a project with a jobs-to-be-done outline, we start development with a data model. Our dashboard, where users can subscribe to an API plan A data model Send monthly invoices, which include charges for several different metered usage line items, and appropriately handle payment and invoice overdue events.Keep track of who is subscribed to what, and how much usage they've accrued, so we can do respond correctly to each API call, and set up the right functionality and UI for each video call.Give our users an easy way to sign-up for (and cancel) subscriptions to our API products.Here's what our new billing and payments code would need to do: We start out most projects by writing up a quick jobs to be done outline. In addition, we knew that Stripe had added quite a lot of functionality to Stripe Billing (Stripe's suite of subscriptions and recurring revenue features) since we'd last had a chance to update our payments code. So writing Stripe-related code is always a pleasure and a learning experience. This promised to be a fun exercise! Stripe's own API design, documentation, and systems infrastructure are the gold standard that all of us who make API-based products aspire to. But when we were planning the launch of a new API product, we realized that the requirements were different enough from what we'd done before that we'd need to write new billing and payments code. We've used Stripe for credit card processing since we started our company, in 2016. Our video calling API is a self-serve product with monthly subscription billing. To learn more, visit our pricing page or read our pricing announcement post. 1: Daily has a new pricing structure as of June 1, 2022.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |