#geordi-subscription-trial
1 messages ยท Page 1 of 1 (latest)
Hi ๐ looking at that thread, it looks like you were asking about using trials to push back the billing_cycle_anchor of a Subscription. Can you elaborate on what is coming across as confusing?
Exactly, sure - I have the backdate_start_date as the first billing date of the other subscription, the billing_cycle_anchor as the next billing date and the trial_end 3 months after the first_billing_date - and errors mentioning that it must be a unix timestamp in the future - i'm not sure how else to achieve this?
should I set a trial start to the next billing date too? then have a trial start and end?
and prorate the next period so the customer is only charged for 9months instead of 12?
Can you share the ID of a request where you saw the error you're referring to?
req_7pcKPUTYKA71Q1
Thank you. Apologies, but I'm not sure I understand why you're setting the trial_end to 3 months from the initial start date?
I think i've confused myself, perhaps it should be set on the next billing date + 3 months?
I'm trying to compensate a customer who is migrating from Braintree to Stripe, by giving them 3 months free after their subscription has been running the past year
But is new on Stripe
Goal example
Product price $100.00
Subscription start date 1st January 2022
Subscription next billing date: 1st January 2023
Their next billing amount should be $75.00 (3 months value)
It feels like it should be do-able with a newly created subscription at least.
Alright, so if you're setting the start date and billing anchor to Jan 1, are these annual subscriptions that you're creating?
That was an example, it could be any date that a customer signed up - yes but can also include annual
So using the above example, what behavior do you see if you set:
Backdate to Jan 1, 2022
Billing ancor to Jan 1, 2023
Trial end to Apr 1, 2023
Hi @spiral swift do you have a follow-up question?
Yes! Given the above case of setting the backdate, billing anchor and trial end past the billing anchor, it throws the error related to this request: req_JFAxj3s3N1myiB
Is the above incorrect? I'm still trying to reach this use case ๐ thanks!
You are passing a trial end date which is after the billing_cycle_anchor date. Is there a reason why you do this? I'm still catch up with the previous discussion.
If you intent to give 3 month free subscriptions to your customer, you can set the billing_cycle_anchor date to a later date (after the trial_end date).
Hmm no just went off the above, no worries - i'm trying to retroactively compensate a customer on their next billing cycle by giving them three months free
But if the billing_cycle_anchor is set after the trial end date - and they have already had a subscription for say 9 months, it will prorate on the whole subscription, not just the 3 months needed right?
I tried it here: req_P0qQ5C5rgZ3QcU
Hmm, I'm still trying to understand why you want to give 3 month trial to your existing customer. If you are backdating a subscription, you just need to set backdate_start_date and billing_cycle_anchor.
we have an example in this doc https://stripe.com/docs/billing/subscriptions/backdating#backdating-billing-cycle can you take a look and see if it fits your use case?
Any ideas? ๐ค
Do you have a chance to read the doc that I sent you earlier?
I didn't receive one!
we have an example in this doc https://stripe.com/docs/billing/subscriptions/backdating#backdating-billing-cycle can you take a look and see if it fits your use case?
Ah shit, that previous message came through now I see - apologies! I will take a look now ๐
We have customers post-brexit who had paid too much tax and we want to compensate them through 3 free months rather than a coupon due to some accounting complexity around reporting - hence backdating the subscription with a trial to prorate the next billing cycle
Thanks for the waiting
Can you try the following
backdate_start_date: 1 Jan 2022,
billing_cycle_anchor: 1 Jan 2023,
trial_end: 1 Oct 2022,
So on 1 Oct 2022, your customer will be billed for the remaining 3 months (Oct - Dec 2022), and on 1 Jan 2023, your customer will be billed again for the whole year of 2023.
It's valid use case and I'm confident that Stripe can support it!
I believe my solution should work for you, try it out and let me know if you have any questions.
I'm confused - should I backdate the original subscription creation date + 3 months? and the billing anchor to the normal next billing date so the subscription on stripe is 9 months? then it would return to normal billing after the year?
If I set the backdate to the original subscription creation date and the billing anchor to the original billing cycle date - it has no affect of proration ๐ I'm sorry for my unclarity
Let me clarify your use case, you want your customer to only pay 3 months of subscription in 2022, and pay full year on the first day of 2023. Am I right?
Example:
Product price: $100.00
Subscription start: January 1st 2022
Next billing date: January 1st 2023
User has already paid $100.00 upfront
on January 2023 I want them to pay 9 months value of a subscription, giving them 3 months free = $75.00 on January 1st 2023
I see. I misunderstood your requirement. let me think again ๐ค
The easiest option would be a coupon 25% off the next billing cycle, but unfortunately have to look at options that aren't monetary driven - hence the weird case ๐
OK, this should work
backdate_start_date: 1 Jan 2022,
billing_cycle_anchor: 1 Jan 2024,
trial_end: 1 Mar 2023
So in this way your customer will be billed 1 Mar 2023 for 9 months, and 1 Jan 2024 for a whole new year.
Sorry the trial_end should be 31 Mar 2023
Ahhh okay. I can explore that option - I'm a little worried around dates in the future that we don't have timestamps for - as these are migrated customers from Braintree therefore we have the original billing date and next billing date... But setting it to 2024 could be off a day or two ๐ค I'll explore!
I would have to advance the next billing date one year I guess
Yes, feel free to play with test clocks
Will do! you can archive this, I'll try it out and if this doesnt work i'll re-evaluate with finance regarding the coupon - much simpler solution ๐
Thank you for your help!
Welcome! feel free to drop by anytime!