To implement a free plan for a subscription, I have created a plan with a monthly charge of $0.
Is this the correct way to subscribe users to a free plan so that they don't have to pay?
Will users still get invoices when they are subscribed to a free plan? If so, how can I avoid sending invoices to those subscribed to the free plan?
Stripe Subscriptions are designed to manage billing and payments, rather than "tracking who is using a product". An "active" Subscription in Stripe is one that is being paid for, rather than one that is "being actively used".
You could conceivably set up a Subscription with an indefinite free trial, but really, you're doing a bunch of work to keep updating it to "remain free". I'd suggest taking a look at what you are actually trying to accomplish, because you're probably trying to track a user of your services, rather than track that a user doesn't pay you anything.
If you want to track a subscription with a zero plan on Stripe it will of course work. I use zero plans all the time.
All the invoices will be generated each month but will have a zero value which means they will automatically be marked as paid.
Invoice was finalized and automatically marked as paid because the amount due was 0.00kr
I am using custom accounts with custom integration so there is no automatic email going out from stripe for me, but I do receive the entire stack of events like I would any normal invoice which i have to deal with.
The event progression is: Invoice created -> finalized -> paid -> changed. Although instant the webhook events all come in.
There is no issue with zero plans, everything shows up in the Stripe admin and works just like any subscription. You can start out with a free plan and upgrade them later - the payment information is gathered and can be charged later so it is all good.
Related
I am working with Stripe to manage subscriptions. I would like to delegate payment of a subscription to another customer.
Specifically, I want the customer of the subscription to reap the benefits of a subscription, but assign another customer to pay for it.
Is that possible? If not, what are the possible workarounds? Thanks.
Notes:
Once a subscription is created, an invoice is automatically generated and is not editable according to what I have tried previously
I would like to keep as close to the usual subscription flows as possible, as I don't want to lose out on things such as being able to pro-rate an invoice (which becomes messy if I have to manually craft invoices myself)
What will be the best pratice to compute monthly allowance of our service when using a Stripe monthly subscription?
I can see 2 strategies:
Add usage to a monthly usage hash (ie. {month_1: 342, month_2: 20}). Calculate current month based on the Stripe subscription start date. Kind of ignore variance in Stripe subscription actual renewal dates, and require manual intervention to block a customer if renewal doesn't go through.
Have a monthy_allowance (credit counter still avaiable for the current month) variable that is replenish when Stripe fires the successful subscription renewal web hook. It's more tie to the actual subscription status, but I can see being an issue as it seems harder to test and subject to bugs if the web hook doesn't properly receive the event. Can be an issue if some customers got locked out until we manually allow them back in.
I suppose it doesn't really matter in this question, but we are using Ruby on Rails with MongoDB as backend.
If you're talking about having some kind of 'usage credit' that your users will 'use up', and that is replenished when a Subscription charge is made, I think you could likely handle this by just having a bucket (like, a counter) that you draw down when they use something, and you fill up when the Subscription is successfully paid, and where you block them (or provide a way to buy more) when the bucket hits zero.
Does that make sense?
Say we've setup a Stripe Subscription plan. i.e. $30/mo. (Note: the billing/account info is stored on Stripe.)
Let's say we want to offer the option to the customer to buy a year of the service upfront, and if they do, they only pay $25/mo (i.e. $300).
Is there any way to conceptually link the "paid upfront" payment, and the Subscription plan? There'll related, except the second one is simply being paid up front, and at a discount because of it.
Or is the second situation simply an unrelated charge to the setup plan/subscription, and just submitted as a charge object?
(I want to make sure I'm organizing payments in Stripe the best way).
There's no universal "best way", it's up to you to decide which way is best suited for your application.
The simplest way, API-wise, would be to create a one-off charge for the yearly amount. But it is then up to you to track that the customer has paid for an entire year and should have access to your service during that time (if that's applicable to your business model).
If you'd rather have the customer being tracked as a subscriber on Stripe's end, what you can do is set up another plan for the correct amount and interval (i.e. $250/year).
Then, when a new customer signs up for this offer, you would:
subscribe them to the plan (this will immediately charge the customer for the $250 periodic amount)
immediately cancel the subscription with at_period_end set to true. This will prevent the customer from being billed again in one year, but will leave the subscription active until then.
We would like to have a yearly plan for our service, but legally we cannot automatically-renew our customer's yearly plan. We need to communicate with our customers in a timely manner within the weeks leading up to the end of their yearly plan so that they will manually purchase another year. (this is a legal thing). So we need some method of setting up a Stripe subscription plan that will either not auto-renew, or that we can cancel via API when we're informed via a webhook that their subscription's year is about to end.
Has anyone had any luck with any creative ways of setting up a non-renewable yearly subscription plan with Stripe? Trying to avoid needing to setup a cron job that hits Stripe everyday to find subscriptions that need to be cancelled.
After contacting Stripe support, there's not an "official" way to do so.
One thought I had was to setup a custom subscription plan of 10 days with a 355 day trial period. That way I could set a webhook to trigger based on the customer.subscription.trial_will_end event.
I'm doing this with the node.js Stripe module.
Well, you could set up a $0.00 subscription, and then a listener for invoice.created webhook, and use that to trigger a flow where you inform the user that their invoice is due, and direct them to a page where they can 'approve' the payment. When they approve it, you could then just create a good old fashioned Charge to collect the money.
Basically, use Stripe as your cron job, and do the actual Charge creation separately.
Today after doing thorough testing i switched to Live Account for Stripe. For my very 1st customer stripe charged twice even though on the server side i am creating just one customer and posting a single charge. I have a monthly subscription plan that i am using.
I never saw this issue in Test Account. I even tried my own card and got charged twice. The two charges are posted within 1 second of each other. I have checked my plan too and they are correctly set up
If you have a monthly subscription, that will automatically make a charge, there is no need for you to be posting a charge when the subscription does it automatically.
(Should have commented but i do not have the rep)
I had the same problem on production not in testing.
I found that if a customer is not a subscriber, my code was making it a customer first and then charging customer. But Stripe is already charged customer upon subscription.
"If(subscriber)->charge
else(make subscriber(Stripe charges now))->charge as customer"
The obvious fix is to make the customer a subscriber and quit if it is a new one, please do not call charge.
The not reproducible on testing issue is because all test accounts were already a subscriber .