#tacologist-sub-schedules
1 messages · Page 1 of 1 (latest)
Can you explain your use case in more depth. Why not do 24 iterations?
I guess I don't understand what you're building
Yes, we have monthly and yearly plans, we will be offering customers to get a yearly plan but pay in monthly installments. We will use subscription schedules to set up their subscription for 12 payments, if they cancel at any point during those 12 months, they will still have to finish the 12 payments and shouldn't be charged anymore after, but if they don't cancel during those 12 months, I want them to enter another yearly subscription paid in 12 installments. Does that make more sense?
tacologist-sub-schedules
Ok you shouldn't need a subscription schedule
Just take the yearly installment and divide by 12
That will be your monthly subscription price to bill users
if they want to cancel, just set the cancel_at date to year end
otherwise they'll keep paying
How do I do that? I thought that wasn't possible to divide the yearly plan insto 12 payments without subscription schedule?
We re not using AfterPay or anything like that
Just a regular subscription
The monthly price will be yearly installment divided by 12
So what is the difference of doing that vs this? https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#installment-plans
I don't understand how to do what you are saying, wouldn't I need to create a new Price to charge that monthly?
How do I just divide the yearly price and bill that?
Subscription schedules just complicate things
They're sometimes necessary
But in your case I don't think you need one
For example if the yearly price is $1200
You'd create a price in stripe for $100
Then create a montly subscription with that price
Customer would be billed monthly
If they opt to cancel, just update cancel_at to whatever date you want (ie year end): https://stripe.com/docs/api/subscriptions/update#update_subscription-cancel_at
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
Otherwise they'll keep getting billed every month
And in this way what would be the correct way of determining how many payments have been made and how many more left? Thats data we want to show our customers
You'd keep track of that on your end
You'd know when you started the sub
And what the end date is
And you can calculate it
And you can keep track of successful payments with webhooks
To me a subscription schedule adds unnecessary complexity here
Okay that makes sense, I will bring it up with the team. Thanks for your help I'll come back if I have more questions
No problem