#Sukatoa-Subscription
1 messages · Page 1 of 1 (latest)
Hi @drowsy stratus Just want to understand your requirement
- For scenario 1.1 -> is it about subscription update (i.e., change price A -> B on Apr 3) + subscription cancellation (i.e., stop subscription at Apr 30) ?
- For scenario 1.4 -> user cancels subscription on Apr 5, free trial on Apr (or May?), charge on the next month (May or July) ? full stopped the subscription at the end of month ( I don't quite get it, why you want to stop the subscription here? are you still going to charge for next month?)
Thanks Jack for the quick response.
For Scheme1.1, we created the Subscription Object on March 5th, the Price Object attached to Payment Method is constant price - we pressumed Stripe will do the recurring charge on every 5th day of succeeding months. When user wants to cancel the subscription on April 3rd, it literally doesn't cancel the subscription yet (controlled by our shop) - but rather let the user finish its current month term. Charging 100% on that month (April 10th). While it's still within April, the user is still allowed to resume. It's more of handling the cancel_at/ended_at.
For Scheme1.4, based on the scheme, free trial period is from March 10th to April 10th, and start charging them on April 10th.
Let's make the business logic simple (Scheme1.4):
- For new users
- They'll be given all the days remaining of the current month as free month
- Starting next month, new users are obliged to pay 100% (on every 10th) of succeeding months (if they continue)
- When the user wants to cancel the subscription, it doesn't mean he wants to cancel the Stripe subscription, but rather wants to stop being charged after the current month
- The shop will continue to charge the user on April 10th (100%), and controls the Stripe subscription to be effective until April 30th
My direct concern here is, if we can charge the users 100% despite the number of days were shrinked - by using the proration_behavior
I know this kinda weird - this is on Japan market where all their credit cards usually charge every 10th of the month. The management also wants to have control to when they want to actually charge the user in monthly basis. So I've added more examples on the scheme
programming it in such a way that for finance dept decision they want to move from 10th to 2nd or 1st of the month, the programming logic will be able to cope up with their demand
OK. If you are using the per-seat pricing model, the customer will always pay up-front, meaning they will pay the full amount in the beginning of each subscription cycle. When you want to cancel the subscription by end of the current billing period (that is, for the duration of time the customer has already paid for), update the subscription with a cancel_at_period_end value of true
Is this what you want to achieve?
Most likely before the current billing period, we want to forcely stop the subscription. But still want them charged 100% during that month they asked to cancel.
so for Scheme1.4, it was set to have free trials from 10th of March to 10th of April. The actual start charge is 10th of April, user cancels it within free trial period. We wanted to follow the business logic we have, so even though they want to cancel it on 5th of April, they are still obliged to pay 100% for April.
Then it's not free trial...
When shop receives request to cancel on April 5th, the shop will modify the stripe subscription and end the subscription forcely on April 30th. What we want to achieve is to charge them 100% with start date from April 10th to April 30th
I know. We had this on previous thread - but the problem with billing_cycle_anchor is it will throw an error if we modify proration_behavior=none if it's following a trial period
This is not how trial should work, trial meaning the customer don't need to pay at all.
I got you. and I agree with you.
but It's already on previous thread, if you have read it
let me send screenshot
It's OK, I understand you now
So you want the customer to start free trial first, and charge them whenever they cancel the subscription, even within the 'trial peroid'.
yes
Then I'll suggest you to start the normal subscription without mentioning the free trial, because it's not a free trial by your product design.
The customer will still get charged eventually, so it's better to make them aware up-front instead of surprising them later.
no no no, i think you don't get it.
- At first, we don't want this way. we want 10th of March to 31st of March as free trial.
- But the accounting wants the actual charge (credit card charge) on every 10th of the month
- Who will manage April 1st to April 9th? billing_cycle_anchor right?
- But we don't want user to have extra charge prioration effect of April 1st to 9th on top of actual upfront charge in April 10th.
As a work-around due to its limitation given the custom business logic they have, we've formulating what Stripe can do in order to follow the existing business rule they have by not shocking users of prioration rate generated on 1st to 9th of the month
that's why, this thread comes in
the scenario, which best fit (i guess) - win-win situation
My only question for this entire thread is:
Would stripe able to charge 100% of user if we set the subscription to start charging on 10th of April, and actually ends on 30th of April?
by using propration_behavior and not throwing errors in the API
By the way, the current Stripe implementation we have now is on the earlier thread - which relies on Stripe's current default way. But they don't want it.
You use propration_behavior when updating the subscription. Can you share with me the code? maybe that's easier to understand,
There's no code existing yet that utilizes that one. that's why I asked a "yes/no" question so I can avoid taking time to do experiments on it.
I can't really answer your question unless I have a full pictures of the question, and let's why I'll ask you the code.
I'll suggest you to test out the code (it doesn't really cost much time), and come back to us if the outcome is not what you desire,
From there we can help you to troubleshoot and recommend the appropriate API/param that you can use in the code.