Lessons Learned with Stripe Subscriptions(blog.cronitor.io)
blog.cronitor.io
Lessons Learned with Stripe Subscriptions
https://blog.cronitor.io/lessons-learned-with-stripe-subscriptions-d6c8d408eb1
20 comments
When will you guys add the failed payment notification emails out of the box ? Been asking this for a while. Webhooks are fine but I feel like a failed payment email should be part of the core just like successful payment emails are.
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.
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.
You don't need to have so many subscription plans to deal with this issue. I built https://quaderno.io to deal with this mess. Let me know if you have any questions. Happy to help!
We didn't. We're going to use metadata to store VAT info. Looked at a few solutions like quaderno and Taxamo, but to be perfectly honest it feels like it adds more complexity to us than it saves us.
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).
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).
> 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.
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.
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.
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.
> 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.)
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.)
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.
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.
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...
Hopefully this will change in 2018 for companies making less than 100k EUR/month: https://ec.europa.eu/taxation_customs/business/vat/digital-s...
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. :-(
We're B2C ...
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:
(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.)
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.)
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-bil...
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.
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.
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.
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/ 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.
- 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.
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.
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.
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.
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.
We use discount coupons with subscriptions and they work as expected: discounts are applied starting from the first payment.
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?
http://Cronitor.IO is a great service. Helps me sleep at night. Thank you for building it.
> 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) - 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.
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.
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.
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.
Thanks for the post. I've been running a small SAAS via Stripe billing and definitely used some of these tricks.
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.
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?
I've used chargebee which is incredible, I don't think stripe or braintree will ever match a real subscription service
You mention that invoicing is a problem that had to be solved manually. Have you looked at services like Recurly or Chargebee?
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).
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).
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!
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!
Does anyone else get about 1/2 of payments failed through Stripe?? It's driving me GD nuts!
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!
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?
What sales channels did you try, and which were most effective?
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.
- 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.
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!
btw, your documentation is top-notch. Kudos to whoever takes the time to make it sparkle!
You mention users not being notified of failed payments -- while Stripe doesn't send emails when this happens, they do provide a webhook.
Very cool tips. I've been considering stripe for a side project and this helped me figure a few things out :)
There ARE services right now for handling invoicing and dunning. I use churnbuster for the latter currently and it is money well spent.
Any good recommendations on the invoicing?
I recommend 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.
I use quickbooks online
[deleted]
Xero.
> 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
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
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.
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.
> 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.
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.
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.
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?
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?
Slava @ Stripe here.
We're currently testing functionality that does exactly this. Shoot me an email to [email protected], and I'll add you to the beta. (Also, would love to work together to iron out any kinks you might run into)
We're currently testing functionality that does exactly this. Shoot me an email to [email protected], and I'll add you to the beta. (Also, would love to work together to iron out any kinks you might run into)
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.
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.
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.
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 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 -- [email protected]. Would love to hear from you and work together to improve the product!