#DeliveryTiem
fervent knoll
Hi vanya! Yes here's the subscription id: sub_1NVs3FIUwLvVicLYzJZiFb39
subtle bough
It seems like you've set cancel_at instead of cancel_at_period_end: https://dashboard.stripe.com/logs/req_wFv7Aa8FvOzJno
fervent knoll
It seems like you've set `cancel_at` instead of `cancel_at_period_end`: <https:/...
We do this because the subscription could be set to cancel to a time further in the future, for example the subscription could be set to cancel during instalment 1 but actually cancel during instalment 5.
This method has proven to work fine for 99% of our subscriptions, but this one is the first one we've experience this with. The only difference with this subscription* was that we had to manually create it via the dashboard instead of via our API. But I do not see how this would cause a proration because the instalment's period ends September 13th and we cancelled on September 13th and set proration to 'none'
Hopefully this makes sense.
subtle bough
Because the Dashboard set the cancellation date to the end of the day, while your application set it precisely to the time when the current period ends.
I see invoice.finalized at 9 am UTC: https://dashboard.stripe.com/events/evt_1NppLgIUwLvVicLYr2Tm27Nc
And customer.subscription.deleted at 23:00 UTC: https://dashboard.stripe.com/events/evt_1Nq2BZIUwLvVicLY4RiA7LUq
fervent knoll
So the time of day that we cancel at matters?
Is it something to do with an offset of the billing anchor's time and the cancellation's time?
subtle bough
It has to be prcisely the time the Subscription renews, otherwise it will charge the customer for the next cycle.
But you can (partialy) refund it afterwards too.
fervent knoll
Okay, does the billing_cycle_anchor time dictate when the next instalment is invoiced?
I ask this just to get a clear understanding of what my cancel_at property's time has to be to stop this from happening again.
I know billing_cycle_anchor date dictates the date that an invoice is made, but does the billing_cycle_anchor time also dictate when the invoice is made on that day?
subtle bough
Okay, does the billing_cycle_anchor time dictate when the next instalment is inv...
Yes
lost willowBOT
fervent knoll
But does setting proration_behavior to 'none' not stop any proration form occurring if a subscription is cancelled at the period end, even if the time is not exact?
To me it's strange that even if I cancel the subscription on the same day as a period ends and explicitly set proration to 'none' that it causes a proration charge.
stray river
Hey! Taking over for my colleague. Let me catch up.
fervent knoll
Hye os4m37, thanks
stray river
But does setting proration_behavior to 'none' not stop any proration form occurring if a subscription is cancelled at the period end, even if the time is not exact?
How the subscription is canceled ? via API ?
fervent knoll
Yep it's cancelled via API. Request id: req_wFv7Aa8FvOzJno
Normally we create subscriptions via API too but we're currently manually creating subscriptions for a particular use-case while we implement an automated workflow for it.
stray river
use-case while we implement an automated workflow for it.
Could you please describe step by step this workflow ? with the request id if there is an API and what is the expectations after each step
fervent knoll
- Existing customer is renewing their product; renewing their subscription.
- User agrees to renew, we call the API to create a new subscription against the existing customer. The golden-path is that the user pays all invoices and then we cancel the subscription when the final invoice is paid.
- The user's subscription could possibly be cancelled pre-emptively at a very future date. For example, during instalment period 2 the customer could have their subscription set to be cancelled at the end of period 5. We always want to cancel at period end to ensure that we do not pro-rata. To cancel via the subscription API, we update the subscription by setting the 'cancel_at' property to be the same date as the end date for period 5 and we set the 'proration_behaviour' to none to make sure the customer is not charged a pro-rata. We expect the subscription to cancel at the end of period 5 and no charge occurs.
We currently do this same logic in an automated manner for new customers who wants subscriptions cancelled at a future date and it works.
At the minute, we are missing the 2nd step of the workflow for the use case, so we have been creating subscriptions via the dashboard. But we already have the 3rd step of the workflow working, so that is why the subscription is created on the dashboard and the API is used to cancel it at the future date.
stray river
First thing I want to mention that proration_behaviour isn't a mode to be set for the Subscription, it has effect only on the changes made for the current request (if there is an immediate invoice) it has no impact on future invoices.
then we cancel the subscription when the final invoice is paid.
Probably you need to use Susbcription Schedule, I think this fits better to your use case
and you set the end_behavior to cancel:
https://site-admin.stripe.com/docs/api/subscription_schedules/update?lang=python#update_subscription_schedule-end_behavior
fervent knoll
I'd love to implement subscription schedules but at the minute we haven't enough time to cater for it. We're tied to old way of using subscriptions at the minute so cancel_at is go-to.
I did not know that was how proration_behaviour worked, okay understood on that thanks for that info. Do we need to adjust cancel_at time to match the billing_cycle_anchor time to stop the pro-rata occurring?
stray river
Do we need to adjust cancel_at time to match the billing_cycle_anchor time to stop the pro-rata occurring?
Yes that could be an option I think
I invite you to test this using Stripe Test Clocks:
fervent knoll
I'll test it out there, thanks for the info appreciate it a lot!