
Lessons Learned with Stripe Subscriptions - encoderer
https://blog.cronitor.io/lessons-learned-with-stripe-subscriptions-d6c8d408eb1
======
coffeemug
I work on Stripe subscriptions. Thanks for the writeup!

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!

~~~
gingerlime
I already reported this to you guys, but I'm curious if others experienced
something similar.

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.

~~~
the_mitsuhiko
> 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...

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.

~~~
Silhouette
On the other hand, if you do B2C, it's just about the only way you can
actually comply with all of the relevant EU tax and consumer protection rules.
Mercifully, B2B is mostly spared that particular nightmare for now, though the
reverse charge mechanism is not exactly fun to work with either.

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.

~~~
beejiu
> reverse charge mechanism is not exactly fun to work with either.

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.)

~~~
Silhouette
_The reverse charge mechanism is great._

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.

~~~
anderspetersson
Yeah, it's abit insane. I spent a week or so implementing this for my saas not
long ago.

Hopefully this will change in 2018 for companies making less than 100k
EUR/month:
[https://ec.europa.eu/taxation_customs/business/vat/digital-s...](https://ec.europa.eu/taxation_customs/business/vat/digital-
single-market-modernising-vat-cross-border-ecommerce_en)

~~~
Silhouette
Let's hope so, though I fear this will be a case of "too little, too late" for
many small businesses. It's been more than two years now since the new system
was introduced, and it seems many micro-businesses have already ceased trading
as a result. Slightly larger businesses have probably either taken on
significant extra compliance costs or ceased trading with customers elsewhere
in the EU. All of that damage has already been done. :-(

------
stevekemp
I love the stripe API, and I like the documentation. But bear in mind you
might want to avoid the subscriptions to cut down on fees.

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).
    

Do that and the user will be billed correctly, but you'll have to pay _two_
fees. That really annoys me, as it seems like a money-grab to charge them
separately not combine the two payments and then take out the fees.

(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.)

~~~
re
Sounds like Stripe has a few suggested solutions for this use case aside from
multiple plans: adding an invoice item, or using quantities that don't map
one-to-one with the quantity of what your customer ordered (in your case,
having a base price of £0.50 with the first domain contributing a quantity of
2x).

[https://stripe.com/docs/subscriptions/quantities#dynamic-
bil...](https://stripe.com/docs/subscriptions/quantities#dynamic-billing-
amounts)

~~~
brianwawok
Yes a free plan with 6 invoice items added via webhook should capture this as
a single bill. At the end of the month stripe pings your server for user X
what is the bill and you respond with your 6 line items.

------
encoderer
Hi HN -- After hacking on Stripe subscription updates over the holidays I
decided to do a quick write-up to share a few lessons learned along the way.
Happy to answer any questions!

~~~
meesterdude
Thanks for the writeup - although I wish there was more substance to it - it's
juuust enough to not be an ad. But that's just the taste in my mouth, first
impressions sort of thing.

What sales channels did you try, and which were most effective?

~~~
encoderer
I wish I had a great answer to this question. If you get one, please let me
know. But here are some details:

\- 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.

~~~
meesterdude
Thanks for sharing this. I would not have expected the first one!

btw, your documentation is top-notch. Kudos to whoever takes the time to make
it sparkle!

------
Keats
We're using Chargebee in our app since Stripe is a bit too simple when it
comes to subscriptions.

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.

------
anderspetersson
Im getting (big) customers that prefer to pay by invoice instead of card.

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?

~~~
coffeemug
Slava @ Stripe here.

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)

------
Rezo
A few more Stripe tips from running a SaaS for a year now:

\- 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/](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.

------
akanet
There ARE services right now for handling invoicing and dunning. I use
churnbuster for the latter currently and it is money well spent.

~~~
coleca
Any good recommendations on the invoicing?

~~~
jot
I recommend [https://quaderno.io/](https://quaderno.io/) used them with four
different kinds of business running through Stripe including a SaaS doing > $1
million ARR. Works great and their customer support is excellent.

------
nathancahill
> Don’t worry about lock-in: a billing migration is not a high leverage
> project for a small team anyway.

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](https://twitter.com/zeeg/status/816074783527796736)

~~~
Silhouette
I tend to agree.

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.

~~~
the_mitsuhiko
> If anything, 4 weeks and 10k LOC seems like quite a lot unless they had
> relatively complicated requirements.

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.

~~~
Silhouette
It looks like you did have quite a few different cases to deal with, then, as
well as the migration from an existing system? If so, that's pretty much what
I meant by "relatively complicated requirements" and I assume would explain
the difference in time and code volume compared to the greenfield
implementation we did. I imagine most early start-ups would have less
challenging requirements than yours for any payment platform integration,
though.

------
Roritharr
I'm the CTO of a german subscription management startup (we also do SMB
Finance Management with our main product).

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.

------
cyberferret
Been using and enjoying Stripe for a while. Good tip about the Webhooks, we
tend to do a LOT of user account processing and clean ups using webhooks to
track failed payments, expired cards etc.

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.

~~~
metafunctor
We use discount coupons with subscriptions and they work as expected:
discounts are applied starting from the first payment.

~~~
cyberferret
Hmm - thanks for the clarification. It must be something in our setups then, I
will check further. Just to confirm - it works OK in your case for brand new
monthly subscriptions where a coupon is applied at the point of sign up?

------
skiltz
[http://Cronitor.IO](http://Cronitor.IO) is a great service. Helps me sleep at
night. Thank you for building it.

------
mderazon
> Stripe as the source of truth

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](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.

~~~
novaleaf
I use Stripe for my SaaS and I agree with you. A lot of the OP's "lessons
learned" I feel are simply opinions based on his own experieince, not actually
determined via cost/benifit analysis with any other comparable workflow.

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.

------
laverick
Thanks for the post. I've been running a small SAAS via Stripe billing and
definitely used some of these tricks.

------
cleverfoo
We migrated scanii.com from Amazon Simple Payments to Stripe subscriptions
(after the whole FPS debacle) and haven't looked back, it's truly the best way
to process payments right now. If I could buy Stripe stock I would.

------
slvrspoon
B2C with less than 100k subscribers. failed billing of card-on-file
"involuntary" in the area of 30% of users. Anyone have data / experience on
how good Stripe is on re-charging?

------
homero
I've used chargebee which is incredible, I don't think stripe or braintree
will ever match a real subscription service

------
drumttocs8
You mention that invoicing is a problem that had to be solved manually. Have
you looked at services like Recurly or Chargebee?

~~~
slantyyz
Invoicing is pretty straightforward if you're using the webhooks.

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).

------
kposehn
Very cool tips. I've been considering stripe for a side project and this
helped me figure a few things out :)

------
no1youknowz
Seen some mentions of Recurly and Chargebee and Sentry did something in 4
weeks of engineering work and 10k LOC.

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!

------
peterschroeder
Does anyone else get about 1/2 of payments failed through Stripe?? It's
driving me GD nuts!

