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?
Related
I am working on stripe subscriptions and have 2 packages basic(400 requests)/month and premium(800 requests)/month and charges 10$ and 20$ respectively. when a user upgrades a subscription, I want to charge a user on the basis of request used. but stripe provides prorated approach and without prorated approach. in prorated approach it calculates payment on the basis of time spent in previously subscribed subscription and remaining time in newly subscribed subscription. but I want to calculate amount to be deducted from my own calculation because it might be possible that the user used only 2 requests in the first 15 days and then upgraded the package. however, I can use usage based pricing model but in this case I have to tell stripe each time that the user requested so increment the count and also stripe has rate limiting per second. how can I achieve it? thanks
I have tried to implement it with stripe schedules
Your best bet is the Usage based pricing model indeed. Read its Doc carefully or the Pricing Model Doc. Avoid Proration in your case, and make sure to report usage to Stripe.
Rate limiting is a different problem and you would need to deal with it regardless of APIs you are calling.
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.
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.
I have a web service which publishes and hosts certain information for my users. Each user's editing interface is separate from the information they've published. I'm billing for it using Stripe subscriptions, but I'm having trouble coming up with a workable way of handling unpaid subscriptions. Here's the logic I want to implement:
Upon the first failed billing attempt, my app should lock down the user's editing interface; instead, it should present them with a page with options for resolving their payment problem. However, information they've published will still be published, so a late payment doesn't interrupt things for their visitors.
Upon the last failed billing attempt, 15 days later, my app should remove information they've published as well. At this point, the user's editing interface is replaced with one that allows them to either re-activate their account with a new credit card, or completely delete the account.
If the user chooses to re-activate the account, they should not get a trial period
If the user re-activates, they should also have to pay for the 15 days they previously skipped out on, either by having their first billing period shortened by 15 days or by having a charge equal to 15 days' service added to their first bill.
#1 and #2 are very easy to implement if I watch for the right webhooks—just redirect requests for a delinquent customer, or a customer with a deleted or unpaid subscription, to a "fix this problem" page. #3 is pretty easy too—just create the subscription with trial_end set to now.
It's #4 that's tricky. How do I determine exactly how long the user's last invoice went unpaid before their subscription was canceled? How do I shorten the first billing period of the new subscription? Alternately, how do I pro-rate the customer's last invoice total to represent the portion that I actually provided to them, so I can add that amount to the new invoice? (I know I can create an Invoice Item to charge for the amount before I start the new subscription, so at least that's a possibility.)
Finally, does Stripe's "Mark Subscription Unpaid" option help with any of this? It looks like it keeps creating invoices but doesn't try to charge for them; I don't think that's what I want here.
You can definitely do all of that with Stripe's subscriptions. As you mentioned, the first two questions should be solved with webhooks. You would listen for invoice.payment_failedon your end to detect when a payment fails and immediately block you UI asking your customer to update their card details.
To update their card details you can use Stripe Checkout and just not set the data-amount parameter so that it doesn't display a price to your customer. Here is an example for this:
<form action="/charge" method="POST">
<script
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
data-key="pk_test_XXXX"
data-image="/square-image.png"
data-name="Demo Site"
data-description="Update Card Details"
data-panel-label="Update Card Details"
data-label="Update Card Details">
</script>
</form>
Each time your customer tries to update his card, you would use the Update Customer API and pass the new card token in the card parameter. This will delete the default card on the customer and replace it with the new one. It will also try and pay the latest invoice of each subscription in the "Past Due" state. In your case it means that the latest invoice still in retry mode will be attempted to be paid. This does not count as a retry and can be seen as independent. If it succeeds, you just reenable the UI otherwise you continue asking the customer to update his card details.
When you reach the fourth failed payment you will get a customer.subscription.canceled if that's what you set up in your retry settings in the dashboard. You can detect that it's an automatic cancelation by checking the request key on the event and making sure it's null. In that case you block the UI/account completely for your customer.
For the last 15 days, if I understood your flow correctly, the customer hasn't really been able to use your application since you locked down the UI partially. But if you still want him to pay for that amount, you should store in your database that the customer owes you $X for the 15 days he couldn't use the subscription.
Later on, your customer finally comes back and want to reenable his account. At that point you inform him that the payment flow will restart from today and that you will charge him for the extra 15 days he missed before. To do that, I would use Invoice Items which will allow you to add an extra amount to the first invoice automatically. You would follow those steps:
Create the invoice item for $X for your customer.
Create a new subscription to your plan setting trial_end to "now" in case you have a trial period set by default on your plan.
This will automatically create the first invoice for the plan amount and add the invoice item created before.
Another solution here would be to reopen their latest closed invoice that wasn't paid and use the Pay Invoice API. When this happens you know your customer paid you for a full month now instead of just the 15 days he owed you. In that case you would create a new subscription and set a trial period of 15 days so that he starts paying again after that trial.
I wouldn't use the "Mark as unpaid" option here because you completely lock the customer out of your application. This feature for me is to be used when you let your customer use your application and plan to charge him in a few months for each of the invoices. This would be used for an electricity provider for example who would keep your electricity on for multiple billing cycles and continue to try charging you for each invoice.
The amount your customer really owes you in that case is dependent on the number of retries you allow and the days between each retry. What you can do here is use the created value on the invoice and compare it to the current time when you get the customer.subscription.canceled to determine how much time passed and calculate the proration of how much your customer owes you at that point.