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.
Related
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.
suppose i have a membership service which cost $10/month in a subscription way
but some users can not have a reusable source to make a subscription via plan api ,alternatively i will let him to do an one-time payment via order api.(at least accept one month's money)
it is the same product,same amount,difference is one is for plan,another is for order,so question is, should i create two products one is goods type(for order),one is service(for plan/subscription). or one service type product is enough?
As a concept in the Stripe Dashboard, product SKUs are only used for recurring plans or invoicing. Any one time purchase can just be a charge, and does not need to be associated with any "Product" within your Stripe configuration.
If the product in this case is literally just one month of the plan, then you should probably use the same Product you have specified.
If the payment method will only work once, you could do nothing, and when the first period is up, and Stripe tries to renew, the payment will fail and the subscription will be canceled.
Or, if you're positive beforehand that it should only be charged once, you could cancel the subscription right after the first payment is completed. The customer would still have an active subscription for the period they paid for, but Stripe would not try to charge them automatically when that first period expired.
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?
My application allows a customer to purchase credits for later in-app use.
I want to enable customers to buy credits throughout the month, and only get billed at the end of the month.
Should I be using a Stripe Subscription at an amount that equals the price of one credit, and change the quantity according to the number of credits the customer purchased?
(After a successful invoice - I'll reset the subscription quantity to 0)
Is there a better solution? Perhaps some clever method of using Stripe Checkout?
Your proposed approach sounds reasonable.
I've not tried it but an alternative I can think of would use a free plan and the Invoice Items part of the API.
Create a free plan with amount with amount field set to 0. As far as I can see from the docs, all the subscription lifecycle webhooks should be triggered for Customers who're subscribed to the plan.
Through the month, create InvoiceItems for the Customer. According to the docs, at the end of the billing cycle, those InvoiceItems are added to the customer's invoice.
Sometimes you want to add a charge or credit to a customer but only actually charge the customer's card at the end of a regular billing cycle. This is useful for combining several charges to minimize per-transaction fees or having Stripe tabulate your usage-based billing totals.
Beyond that, you'll want to consider if you should have Stripe generate/email your invoices.
I don't think this is the way to go, because subscriptions are billed the first time among other things.
The recommanded way is: stripe doc: Place a hold on a card
summary
You first ask authorization for a certain amount (the max amount). Eg: 1000$
Your custommer buy 50 credits in the month
At the end of the month you charge the customer for 50$ (it can not be greater that the maximum you authorized in the first step)
That's all :)
This question is for anyone who's experienced with Stripe. I've run into a situation that may be pretty specific, but I'm hoping I could get some help with. I am creating a system where a user can pick from many different options and set up a yearly subscription based on their selections. So there is no set plan cost, the subscription cost is variable.
Now, if someone creates a subscription for $100.00 dollars, then in a month decides next year they'd like to reduce their subscription to $50.00 they can do so. However, they will not receive a prorated refund due to the downgrade for the current subscription period. My issue is, let's say they change their mind and realize the $100.00 service is worth it. So much so they actually want to change their subscription from $50.00 to $120.00 in the current subscription year. I would like to charge them a prorated fee, but if I do that they will be charged for the difference of $50.00 and $120.00, not $100 (which they paid originally) and $120. Is there anything I can do to allow for such a situation to occur?
I'm thinking that in order to make this work I'll have to implement the calculation of a proration amount myself. So in the case a user pays for a $100 subscription, downgrades to $50, and then sometime later in the same year upgrades to $120.
The solution I see is to save the maximum amount they've paid for their subscription in my local database record. When they upgrade, if their new plan cost is greater than the maximum they've paid, I need to set their stripe subscription to the new amount without proration, then calculate the difference between the max they've paid and the new plan amount, prorate the cost and charge them manually using a stripe charge. Kind of a roundabout way to do it but it accomplishes the goal as far as I can see at the moment.