9 ms·

Lessons Learned with Stripe Subscriptions

210 points by encoderer 10y ago

encoderer 10y ago
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 10y ago
  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 10y ago
    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 10y ago
      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!
- ihsw 10y ago
  You mention users not being notified of failed payments -- while Stripe doesn't send emails when this happens, they do provide a webhook.
kposehn 10y ago
Very cool tips. I've been considering stripe for a side project and this helped me figure a few things out :)
akanet 10y ago
There ARE services right now for handling invoicing and dunning. I use churnbuster for the latter currently and it is money well spent.
- coleca 10y ago
  Any good recommendations on the invoicing?
  - intrasight 10y ago
    I use quickbooks online
  - deleted 10y ago
    [deleted]
  - ebcase 10y ago
    Xero.
  - jot 10y ago
    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 10y ago
> 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 10y ago
  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 10y ago
    > 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.
anderspetersson 10y ago
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?
- encoderer 10y ago
  It's not the best solution, but if the plan you subscribe them to is $0 in Stripe you shouldn't have a problem. This is currently what we do. I'd love to hear a better answer, though.
- jarcoal 10y ago
  Here's what we do: 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.
- lukenyc 10y ago
  What we do is process a check in our admin which hits Stripe's API to create the customer if necessary (no payment source necessary when doing this via API in our experience) and then adjust the customer's account balance by the amount of the check. Then we process the customer's subscription and Stripe automatically debits the customer's account to pay the invoice.
- coffeemug 10y ago
  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)
cleverfoo 10y ago
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.
laverick 10y ago
Thanks for the post. I've been running a small SAAS via Stripe billing and definitely used some of these tricks.
stevekemp 10y ago
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 10y ago
  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-billing-amounts https://stripe.com/docs/subscriptions/quantities#dynamic-bil...
  - brianwawok 10y ago
    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.
drumttocs8 10y ago
You mention that invoicing is a problem that had to be solved manually. Have you looked at services like Recurly or Chargebee?
- slantyyz 10y ago
  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).
skiltz 10y ago
http://Cronitor.IO http://Cronitor.IO is a great service. Helps me sleep at night. Thank you for building it.
coffeemug 10y ago
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 10y ago
  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 10y ago
    > 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 10y ago
      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.
cyberferret 10y ago
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 10y ago
  We use discount coupons with subscriptions and they work as expected: discounts are applied starting from the first payment.
  - cyberferret 10y ago
    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?
Keats 10y ago
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.
Roritharr 10y ago
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.
no1youknowz 10y ago
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!
mderazon 10y ago
> 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 10y ago
  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.
Rezo 10y ago
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.
peterschroeder 10y ago
Does anyone else get about 1/2 of payments failed through Stripe?? It's driving me GD nuts!
homero 10y ago
I've used chargebee which is incredible, I don't think stripe or braintree will ever match a real subscription service
slvrspoon 10y ago
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?

210 points by encoderer 10y ago

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 10y ago
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 10y ago
  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 10y ago
    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!
ihsw 10y ago
You mention users not being notified of failed payments -- while Stripe doesn't send emails when this happens, they do provide a webhook.

kposehn 10y ago

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

akanet 10y ago

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

coleca 10y ago
Any good recommendations on the invoicing?
- intrasight 10y ago
  I use quickbooks online
- deleted 10y ago
  [deleted]
- ebcase 10y ago
  Xero.
- jot 10y ago
  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 10y ago

> 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 10y ago
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 10y ago
  > 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.

anderspetersson 10y ago

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?

encoderer 10y ago
It's not the best solution, but if the plan you subscribe them to is $0 in Stripe you shouldn't have a problem. This is currently what we do. I'd love to hear a better answer, though.
jarcoal 10y ago
Here's what we do: 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.
lukenyc 10y ago
What we do is process a check in our admin which hits Stripe's API to create the customer if necessary (no payment source necessary when doing this via API in our experience) and then adjust the customer's account balance by the amount of the check. Then we process the customer's subscription and Stripe automatically debits the customer's account to pay the invoice.
coffeemug 10y ago
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)

cleverfoo 10y ago

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.

laverick 10y ago

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

stevekemp 10y ago

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 10y ago
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-billing-amounts https://stripe.com/docs/subscriptions/quantities#dynamic-bil...
- brianwawok 10y ago
  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.

drumttocs8 10y ago

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

slantyyz 10y ago
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).

skiltz 10y ago

http://Cronitor.IO http://Cronitor.IO is a great service. Helps me sleep at night. Thank you for building it.

coffeemug 10y ago

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 10y ago
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 10y ago
  > 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 10y ago
    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.

cyberferret 10y ago

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 10y ago
We use discount coupons with subscriptions and they work as expected: discounts are applied starting from the first payment.
- cyberferret 10y ago
  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?

Keats 10y ago

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.

Roritharr 10y ago

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.

no1youknowz 10y ago

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!

mderazon 10y ago

> 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 10y ago
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.

Rezo 10y ago

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.

peterschroeder 10y ago

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

homero 10y ago

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

slvrspoon 10y ago

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?