Subscriptions @ Deskera
Subscription as a concept is not new. It has been an integral part of any business dating back to, dare I say, the very beginning of time when people started conducting business and subscriptions aren't rare either. You probably have at least 10 active subscriptions that you pay for. It is probably a key evaluation metric for any business. At Deskera, we have built a very flexible subscription engine which helps you to customize your usage.
First of all, a subscription isn’t a recurring payment. I mean, it isn’t just that. That’s only one part of it. There are other pieces to any subscription engine.
a. Collecting payments,
b. defining pricing plans,
c. defining features/coupons, and
d. invoicing.
Payments : There are many payment service providers available. We started our integration with Stripe because Stripe offers very good documentation of their APIs with ready to use libraries or packages which really makes integration super quick & easy. Node, PHP, GO, Java whichever suits your needs. We love the simplicity of GO and that’s where our bulk of subscription engine code is written in. Stripe also allows the creation of these various sandbox accounts that is very useful in development phase, we use multiple accounts for Development, QA and Production environments.
IMP things to take care of : To ensure PCI compliance do ensure that you don’t store any Card or Payment related information on your servers.
Now to be upfront, Stripe also offers very good subscription APIs: https://stripe.com/docs/billing/subscriptions/creating
These are pretty good and could cover most of the cases, in-fact we started with these APIs first but then soon realised that to have a better control for our offerings, we should write our own. This also keeps our subscription and payment processing de-coupled so we could offer services in regions where say Stripe isn’t available or something else is more popular with customers.
Plans : We create Plans which have attributes like : Interval, Duration, Price, Trial Period. These are stored in MongoDB and we chose document database over relational databases because we figured that flexibility is going to be key in our implementation as Plans and Features will have to be flexible. We would want to tune the features in.a plan, introduce new plans based on the feedback from our sales team or just have the ability to apply little tweaks quickly as business evolved.
Features/Coupons: Plans also define features. Features could be rate limited, say invoices a month or say could be a UI feature, say reports. We have de-coupled features from plans, though they are related, to allow us flexible compositions of plans. Another key feature is Coupon which has its own attributes, like Duration, Applicability (how many times one can apply this) , Redeem-ability (how many users can redeem this ) and percentages or discount amounts.
Invoicing: So now users have subscribed, trial is over, you got to compute usage and charge appropriately. We accomplish this by running queries over our User Management services and other micro services which maintain information about invoices created, bills, etc.. anything that acts as a measurement for the features that we offer. And this basically runs a job that will charge our users with their stored payment methods.
Lastly, our subscription engine is implemented in GO, running in a docker container and hosted on a Kubernetes Cluster on AWS. I will share more details in an upcoming post about implementation.
