#DeliveryTiem-subscription
cursive oasis
I now have a problem, there is a grace period after the product cancellation date where the customer can revert the product cancellation and continue to use the product.
For this piece, can you clarify whether this is the behavior that you're current seeing, and if so how the Customers are doing that, or whether this is a flow that you're trying to offer?
fiery lantern
Workflow we are trying to offer, we have no such implementation now
cursive oasis
We do have the functionality to pause payments for a Subscription, so I think combining that with setting the cancel_at date further in the future may accomplish what you're looking for:
https://stripe.com/docs/billing/subscriptions/pause
Just in case you haven't seen it yet, I strongly recommend using Test Clocks for testing these types of scenarios:
https://stripe.com/docs/billing/testing/test-clocks
fiery lantern
I had seen that pause ability, this only allows pausing immediately and not a date in the future, we could have 2 or 3 payments before the cancellation occurs. Though with the absence of a 'pause in the future' ability, perhaps I can make a daily scheduled task that checks upcoming product cancellations and set them to pause, then once they have went over the grace period I can fully cancel the subscription.
Thanks for reminding me i've been wanting to get onto using test clocks
cursive oasis
Ah, gotcha, we do have something for scheduling future changes to a Subscription, they're called Subscription Schedules:
https://stripe.com/docs/billing/subscriptions/subscription-schedules
cursive oasis
I need to step away soon and am archiving this thread. If there is anything else that my teammates can assist with, then please let them know in #dev-help. 👋 (holding off as I see typing)
fiery lantern
Been doing some looking into the schedules API and formulating some ideas on implementation, I've gotten enough information to make some decisions. Step away and enjoy the day, thanks Toby
Overall I can see a decent path toward setting up the subscription to be triggered to pause on my product's cancellation date, then cancel it when the cancellation revertion period has past
cursive oasis
Glad to hear! Thank you, hope you have a good day as well. Let us know if any of that implementation gives you trouble and we'll be happy to help.
verbal oar
👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!
fiery lantern
Hey @verbal oar 👋 I will do!
fiery lantern
Two questions: 1.) does creating a new subscription with a verified payment method used on a previous subscription require the payment method to be re-authenticated by the customer or any sort of customer interaction needed? 2) Can a new subscription be back-dated to have a payment due in the past e.g. today is the 25th July, I create a new subscription today but back date the subscription to of began on the 1st July and create an invoice that was due on the 15th July?
verbal oar
1.) does creating a new subscription with a verified payment method used on a previous subscription require the payment method to be re-authenticated by the customer or any sort of customer interaction needed?
where is the payment method stored? on the subscription itself or on the customer level? is it a Card payment? does it require 3DS?
- Can a new subscription be back-dated to have a payment due in the past e.g. today is the 25th July, I create a new subscription today but back date the subscription to of began on the 1st July and create an invoice that was due on the 15th July?
https://stripe.com/docs/api/subscriptions/create#create_subscription-backdate_start_date
fiery lantern
> 1.) does creating a new subscription with a verified payment method used on a...
Need to clarify whether payment method is stored on the customer or the subscription, gimme a few mins
fiery lantern
> 2) Can a new subscription be back-dated to have a payment due in the past e.g....
Thanks that's exactly what I needed for that
fiery lantern
> 1.) does creating a new subscription with a verified payment method used on a...
It is stored at the customer level, can be card payment or ACH, card payments can have 3DS
verbal oar
if the PM is save on the customer level, it should also be set on the invoice_settings.default_payment_method field https://stripe.com/docs/api/customers/object#customer_object-invoice_settings-default_payment_method
in that case it will be automatically used as the new subscription's PM unless specified otherwise
as for the 3DS whether it's the old or the new subscription there's always the chance that the issuing bank would demand a 3DS verification of an off_session payment. You should be handling these cases regardless of this use case
fiery lantern
Got side-tracked there, this is all good to know and works for our case. We are handling 3DS regardless as is. From a high level I am between two implementations to solve the problem, which I will do more work to determine which one is best:
1.) Set subscription to cancel at product cancellation date, if customer wants to revert product cancellation after it is cancelled we create a new back-dated subscription that starts from the date the subscription was cancelled, back-dating will invoice any payments that should of been paid between cancellation and reinstatement.
2.) Pause subscription at product cancellation date (with invoices marked as drafts that fall into the 'paused' time), if customer wants to revert product cancellation we resume the subscription, if not then we cancel the subscription after the cancellation grace period has passed.
Great direction overall so thank you
hollow bobcat
Hi 👋 I'm stepping in for @verbal oar as they needed to step away.
There's a lot to catch up on here so give me a minute
fiery lantern
Hey @hollow bobcat 👋 yes there's a bit take your time
hollow bobcat
Depending on the length of your billing cycles it might make sense to allow a customer to set a subscription to cancel at the end of their current billing cycle. This allows them the time to change their mind before that time is reached and you don't have to worry about prorations. You would use the cancel_at_period_end parameter: https://stripe.com/docs/api/subscriptions/update#update_subscription-cancel_at_period_end
fiery lantern
Thanks, so for example if I have a monthly subscription that was most recently paid on the 20th July and I use cancel_at_period_end today, it will not take a payment for the next month (e.g. 20th August) and the subscription will be cancelled
hollow bobcat
Right, the subscription will remain active up until August 20 but at that point it will cancel and not attempt further payments
And then your integration can allow the user to switch the cancel_at_period_end to False any time before August 20
fiery lantern
That can work for me in implementation #1, that's great thank you