Lessons learned with Stripe subscriptions
In June, 2014 we shipped an MVP for Cronitor that was so basic I cringe a little when I think about it. It didn’t do very much, most features were cut, but it shipped with paid subscriptions on day one. We sold one to a friend.
My earliest work on subscription integration was primitive: The first month’s charge was captured during the upgrade but we created each subscription by hand in the Stripe dashboard. It sounds sketchy but recurring billing is just not a problem that needs to be solved by launch day. Now, 2.5 years and 2 iterations later, I’ve had time to meditate on a few lessons learned.
Embrace the platform
Don’t worry about lock-in: a billing migration is not a high leverage project for a small team anyway. As a Stripe user this means:
- Use coupons to manage price segmentation, reducing overall number of plans.
- For usage based or variable billing, push the quantity of users or widgets consumed to Stripe. Don’t try to manage these line items directly from your code.
- A plan in your app should map 1:1 to a plan in Stripe. If you have monthly and yearly options for a plan, this is actually two plans. Define feature sets in your code that can be shared among multiple plans to simplify implementation.
Stripe as the source of truth
Your code will need to know which plan a user is subscribed to, but the source of truth for these details should remain in Stripe.
- Stripe webhooks are incredibly reliable — they are versioned and retried on failure. Use webhooks to push necessary details to your application.
- If you offer a free plan, create subscriptions for these users in Stripe. You will be able to find and manage all users from your Stripe dashboard and there will be fewer conditionals in your code if every user has a subscription of some kind.
- With webhook integration the Stripe dashboard can become your billing UI. Save yourself the effort of rebuilding it with API calls.
There are a few missing pieces
Stripe has a well deserved reputation for quality but they have plenty of work yet to do.
- Invoicing users must be done manually today using a webhook. Stripe sends payment receipts but they lack the details many companies need on an invoice. At Cronitor we created invoices in Excel for several months until we found time to hack on this. We hoped Stripe would beat us to it. Two years later they still haven’t.
- Failed payment retry logic is limited. Failed charges can only be retried three times and there is no notification to the user when their payment fails. We’ve found it’s best to give users 4–6 weeks to resolve failed payments with 1-2 reminders per week. None of that is possible today without dev work.
Monitor important Stripe events
Cronitor is built to monitor scheduled jobs, workers, and services but it can also be used to consume Stripe webhooks and send notifications to your team:
- Be notified instantly of failed or disputed charges.
- Trigger an alert if no subscriptions have been created recently.
