Lessons Learned with Stripe Subscriptions
blog.cronitor.io
blog.cronitor.io
We have quite a bit planned to improve the subscriptions logic (including fixing the issues mentioned in the post). If you have any questions, suggestions, or feedback, please shoot me an email -- slava@stripe.com. Would love to hear from you and work together to improve the product!
Tax, and particularly VAT in the EU, is a real pain to deal with. Stripe does offer `tax_percent` to be added to invoices, but unfortunately this can only be added on top of the price. This means, that if I want to offer a flat price to all EU customers with VAT included, things get messy. Either I do my own tax thing separately (or via metadata), or I have to create a bunch of different subscription plans, each for every VAT rate in different EU countries...
If the `tax_percent` could be deducted from the full amount, rather than added on top, this will solve this in a much cleaner and simpler way.
Paypal integration would also be really helpful, particularly for subscriptions.
Please don't do that if you do B2B because it means that people from different countries get different prices as business customers when they get VAT reimbursed. Also please provide reverse charge if possible.
It would certainly be helpful if Stripe made it easier to reconcile everything needed for those EU VAT returns. Some essential things like determining the exchange rate that was applied for a particular transaction if you work in multiple currencies remain quite awkward. The deposits from Stripe into merchant bank accounts also still don't seem to have any reference supplied so you can trace them back through the API to find the underlying charges, refunds, etc.
It is nice that they show the country of origin for the card now, though. At least that gives most merchants a fighting chance of keeping enough evidence of where every customer is based to satisfy the EU VAT rules.
The reverse charge mechanism is great. The alternative system was to register for VAT in all 28 EU member states and file returns in each state. The reverse charge mechanism means if you are exporting services, you only have to deal with the your local tax authority. (Unless your customers are not VAT registered, then you have to make sure you stay under the threshold in each state.)
Well, it's better than the old alternative you mentioned, but that's a bit like saying the MOSS scheme is great because otherwise you'd have to register and file returns in every EU member state where you sold a single £5 knitting pattern PDF from your kitchen table business. Being better than a system so insanely disproportionate and over-complicated that small businesses would have no hope of complying isn't particularly impressive.
Hopefully this will change in 2018 for companies making less than 100k EUR/month: https://ec.europa.eu/taxation_customs/business/vat/digital-s...
If stripe supported tax_percent deducted from the full amount, it would make things even more elegant (and could be useful for you guys as 3rd party integrations I imagine).
Pretend you sell apples and oranges. If the user has 3 of each you might be tempted to bill the user for:
3 * Apple Subscriptions (/month).
3 * Orange Subscriptions (/month).
(This contributed to me removing my discounted-pricing plans where you could spend £1 a month for DNS hosting, but then get additional domains at £0.50. Instead I kept everything at £1 so that I didn't have to have different subscription levels.)
https://stripe.com/docs/subscriptions/quantities#dynamic-bil...
What sales channels did you try, and which were most effective?
- Our most valuable source of traffic has been Google. Spending time to write good documentation has always paid off twice for us as more surface area for Googlebot.
- When we launch new features and tweet about them, promoting those tweets has worked well. Running promoted-tweet campaigns not tied to a feature release has not worked as well.
- We did our part to pad Google's bottom line with an array of targeted adwords campaigns that we tried over a couple months with poor results.
btw, your documentation is top-notch. Kudos to whoever takes the time to make it sparkle!
I'm thinking something like Chargebee/Recurly should be open-source, with a gitlab model and with charts like chartmogul.com built-in as well to centralize all subscriptions info/reporting. I'm not sure whether the open-source aspect would be enough to convince enough people to use it, but it would convince me at least.
I would like Stripe to handle these subscriptions as well, for example send a webhook on subscription end. But it seems like you can't add a subscription to a customer who dsn't have an active payment source. Any ideas?
Give the customer a very short trial (5 minutes) and put them on the plan they want. After a couple hours, come back when the invoice failed to charge (because they have no payment source) and close/forgive the invoice.
That will keep the subscription running as expected and keep your analytics (Baremetrics, Profitwell, etc) accurate. When the next cycle comes around, you'll get charge failed notifications from Stripe and you can do it all over again.
We're currently testing functionality that does exactly this. Shoot me an email to slava@stripe.com, and I'll add you to the beta. (Also, would love to work together to iron out any kinks you might run into)
- A discount coupon can either be applied at the customer, or the subscription object level. The first persists across subscriptions (even while cancelled in between), but the later takes precedence if both types of coupons are present.
- There can only be one single coupon in effect for a customer at a time, therefore I would caution against the article's suggestion to use coupons purely for price segmentation as you "use up" that capability which you might regret later on.
- When you sell a multiple of something, make the Stripe plan cost representative of one unit of the thing (the smallest unit you think you'd sell, like a single user), even if there's a pricing floor in effect (X units required). This makes it so much easier to allow users to upgrade by an arbitrary amount of units. Learned this the hard way.
- In general, use the quantities property of plans, instead of creating a ton of different plans. I see a lot of "5 user", "10 user", etc. plans in the open Baremetrics data, which seems like a bad idea to me.
- If there's a discount built into your annual plan, just make that the base price of the annual plan. This frees up the coupon slot as per above for volume discounts or whatever.
- Annual plan pro-rating default behavior is broken in my opinion. If the plan type or quantity changes during the subscription period, the customer will pay for this only with the next invoice, which can be up to a year later. This is almost certainly not what you want, or what the customer expects. Instead, you have to manually (programmatically) create an invoice and trigger a payment to "sweep up" the price delta for the new plan. Ideally this could be done by Stripe on a monthly basis (it has to be delayed, you don't want to do it immediately since the customer might make more changes in a short period of time and you don't want to bombard them with receipts).
- http://www.ultrahook.com/ is great for testing & developing the Stripe webhooks locally
- It's a very rich ecosystem. I use 3rd party services that save me considerable time over building it myself for Stripe dunning, analytics and even professional looking receipts (customization, PDF rendering, VAT info, bulk downloads etc.), help desk integration etc.
That's true at first, but maybe do worry a little bit about lock-in down the road? Sentry just replaced Stripe's subscription management with their own to add missing functionality. 4 weeks of engineering work and 10k LOC: https://twitter.com/zeeg/status/816074783527796736
If anything, 4 weeks and 10k LOC seems like quite a lot unless they had relatively complicated requirements. The last time we implemented subscription billing, there were requirements to support multiple payment platforms and a variety of configurable plans but otherwise it was fairly routine stuff. Implementing and testing the entire thing, including the customer-facing sign-up process, a simple database to track subscribers and payment information, and the API calls and webhooks for each platform to manage the payments and update our electronic records, took us about a week and maybe 2k LOC, if memory serves.
Running your own subscription billing logic probably isn't the #1 priority for most start-ups, and I certainly wouldn't criticise someone who said they had more important things to do and left it to Stripe or whoever to set up the charges for a while, but it really isn't that big a deal technically. If you're using any of the modern services that has a decent outgoing API to set up the charges and decent incoming webhooks to track their progress, it's the kind of thing you can do in a matter of days.
With that in mind, I would tend to disagree with much of what I'm reading in the original article and some of the other comments here. Outsourcing not just your payment collection but also things like your essential record-keeping to a third party seems like an unnecessarily risky degree of dependency and lock-in to live with beyond the early/experimental stages of a business.
Armin from Sentry here: it's not even all that complex. However there are many details that need testing including prorating when changing from one to the other plan, from old to new billing system, from monthly to annual and reverse and in our case now completely elastic billing. Then obviously there is dealing with failing charges and retrying and all that which goes with it. Just gets complex very quickly in a critical part of the business: where money is made.
Stripe is one of the nicest PSPs to work with and we're happy that they make it easier for people to get started with subscriptions, since it's a demanding task to get interested customers to understand the inherent design concepts/issues of subscriptions before creating their subscription process.
If the onboarding is not done well and doesn't include some basic education, businesses can quickly end up in situations they didn't expect, for example when it comes to combinations of upgrades/downgrades combined with coupons, allowing customers to offset the already paid for value pro-rata for the new product...
If you want to allow that, you have to think about what your preferred business logic for that situation is, what incentivizes what, and sometimes even if the law of the customers country legally allows for certain practices. (It nearly always does, but there are some exceptions that need to be added to Terms of Service)
So we're looking forward to see more businesses in Europe offering subscription based services, compared to the US the market still has a lot of catch up to do and we're happy stripe wants to help with that.
One tip - if you have more than one web app that you want to bill for, please be aware that you can set up multiple 'companies' under the one Stripe account. It took us a while to figure this out, and at one stage we were trying to handle callbacks for 4 different web apps with one central webhook endpoint. (As Stripe only allows you to specify one webhook endpoint per company).
Using multiple companies we can now have each web app handle their own webhook callbacks. Plus we can also isolate the customers, subscriptions and plans for each web app. Everything still goes back to the one central bank account for the parent company, but managing each individual app is a breeze.
Another caveat: Be careful with the discount coupons in Stripe when using against subscription plans. For some reason, the discount is NOT applied to the FIRST month's subscriptions, but only on subsequent ones, necessitating a manual refund of the difference to the customer for their first month's payment.
I don't feel very comfortable with this.
Also, we manage subscriptions internally within our own code. Didn't want to lock in too much to Stripe so we are basically creating Stripe customers upon adding a payment method and then charge them when the time is right and as many times as we want (recurring). Gives us more flexibility and keeps the control in our hands.
I always had a thought about moving to some other processor someday so I didn't want to dive deeper with Stripe integration and goodies.
Also, I have recently thought about using a service like Spreedly (https://www.spreedly.com) - basically it lets you use a Stripe like API but behind the scenes choose and swap any payment processor you like (Stripe included). I am curious to know if anyone have experience with them.
My subscription workflow is almost exactly like yours, for similar reasons, but also I convert subscriptions into a credits/day system that I track internally, and based on the Stripe API this doesn't seem like a good idea to try to have Stripe track for me.
Using Rails as an example, all you need to do is set up a mailer that's invoked from your stripe webhook controller. It's also more versatile, because the built-in email receipts that Stripe sends out have a limited amount of information and don't take advantage of the metadata fields you can create on your subscription objects.
I've only got two minor complaints with trying to integrate Stripe for subscriptions - there's basically only TEST/PROD - you can't have more environments than that (I have to use a separate stripe account for dev), and that the webhooks don't work if your dev machine is behind a firewall (I use Ultrahook to get around that, but I find that it quits on me constantly).
With that said, are there any open source solutions that come close to not needing a 3rd party? I say close, as covering the loss with development time is not a problem in my case.
Unfortunately, I am not able to use Stripe.
Thanks!