#sai_rez-subscription-cancellation
edgy oxide
Sure, here you go
sub_DuaAkYTPl34FRq
And for comparison, here is the sub id of a user with the correct outcome
sub_1JozhmLmu5QiBx4BFX53zIzY
It would be great to know why the first users sub didn't cancel like the second user
worldly ice
Taking a look
edgy oxide
Thanks
worldly ice
What makes you think that that subscription should have been automatically cancelled?
edgy oxide
We were testing running a script to go through subscription unpaid customers who had a failed invoice followed by multiple draft invoices. In discussion with another dev on here he mentioned this was the case after marking the invoices void/uncollectible
I have a few test users in test mode I ran the script against and all their subs canceled correctly, the second subscription I provided above cancelled correctly also
I'm curious to know more about how this works and why it didn't seem to cancel this particular user
crimson yoke
not sure! I asked some colleagues
light turtle
@edgy oxide I'm looking into it right now. This is surprising but I haven't found a good answer just yet. The actions are a bit too old (over a month) so I don't have access to much details. will dig for a bit longer though
edgy oxide
Awesome thanks so much
If you would like I can find a similar user in test mode to run the script on and you can have a better idea through there?
light turtle
All good I did it on my end with Test clocks. And I see the behaviour of unpaid -> active after voiding the most recent invoice
but that's the opposite of what I expected too
edgy oxide
That's interesting, did the account you tried have a failed invoice followed by multiple draft invoices?
light turtle
hmmm
no not yet, I just voided the most recent and only invoice
let me try with more draft, I'll be back in a few minutes!
edgy oxide
So this would be a scenario to ideally test with
What our script does is the mark the failed invoices as uncollectible and finalises the draft invoices then marks them as void
light turtle
yep working on it, test clocks taking a while to advance multiple months :p
edgy oxide
No worries, thanks again
light turtle
do you start by the most recent?
or do you start by oldest and finally finalize + void the draft one?
light turtle
okay so you mark the only failed one uncollectible and then by oldest draft first you finalize then void
edgy oxide
Yes correct
light turtle
ack, let me try that
damn you can't even do this in the Dashboard, going to have to write a script
edgy oxide
I can send you mine haha
light turtle
nah I'm good, will take a bit longer, still feels like a bug anyways
Like my gut was telling me voiding should not cancel the subscription. But it also should not bring it active, so either way feels wrong.
But your experience/previous tests made you think voiding the last invoice should always cancel the subscription?
edgy oxide
Im not certain it's the last invoice, initially I called the subscription cancel method at the end of the loop but noticed I received errors in the logs saying the sub is already cancelled, so that when I reached out to stripe and was informed the subscription got cancelled by the time I reach the end of the process if that makes sense
light turtle
hum
so yeah I just tried again your flow and my subscription goes to active
I don't get why but it seems to mirror what you experienced before where you then would cancel, right?
And so the question is: why did the voiding of that one invoice ended up automatically canceling
not why did the voiding led to active, right?
edgy oxide
If you would like I will send you this account on our Perlego Test account with test mode on and you can see what happens when I run the script?
cus_K4FSVks1dp2fxw
Can you view this customer?
light turtle
sure, but I think I just need one peice of info from you now
out of all your subscriptions, did they usually go unpaid -> active then you cancel. Or did they go unpaid -> canceled
edgy oxide
So judging by the logs, it looks like it cancels from unpaid
light turtle
looking
hmmm I don't get what the screenshot tells me
Sorry I'm just trying to understand your position right now
you seem to have a script, I assume you did this dozens of times recently and once were thrown off by the behaviour being wrong
is that incorrect?
edgy oxide
So it was to answer your question above, if the sub going from unpaid -> active -> cancel or unpaid -> cancel
From the logs it looks like it's the latter
light turtle
well it looks like it's random then since I literally saw the opposite
edgy oxide
I'm not sure, it's what I'm trying to better understand as we had the initial customer I mentioned not behaving the same way as other users
light turtle
sure but that's my question
I don't want one example, I want to understand what you expect. If you did this to 100 customers and they all went to canceled but one went to active, then you expect canceled.
So which one do you expect.
edgy oxide
Ah sorry, yes I expect all to be cancelled
light turtle
okay. Can you
1/ Run the test on the customer you mentioned
2/ Show me at least 4 separate subscriptions where they did unpaid -> canceled without moving to active since you expect this to be the right behaviour
edgy oxide
Okay no problem, for step one I will run the script on the test customer on our Perlego Test account, for your second point the subscriptions will come from our Perlego account
So you are aware we're dealing with two accounts
light turtle
yes that shouldn't matter
okay your subscription did unpaid -> canceled on that customer too
edgy oxide
okay. Can you
1/ Run the test on the customer you mentioned
2/ Show me at least ...
1/ sub_K4FSIVoGajQCLE - I ran the script against this user, sub is cancelled now
2/sub_1Ji58hLmu5QiBx4Bg37JjHVg, sub_1JhjQtLmu5QiBx4BC2vFmhWR, sub_IkbY2AX0DHsOV2, sub_1JfSkpLmu5QiBx4BD6ui0x7i - 4 subs where they cancelled
light turtle
perfect thank you!
damn I don't get why yours are clearly canceling and mine are going to active 😅
edgy oxide
Are both bugs haha? What is the expected scenario officially?
light turtle
I wish I knew
my take was that the subscription stayed unpaid which is not an option of what we even see
oh wait
did you change the settings for your account?
like to get a subscription in "unpaid" you have to have had, at some point, the retries configured tomark as unpaid
and it seems now you have "cancel"
edgy oxide
I believe there was a change on our setting where if an invoice fails 4 times it gets marked as uncollectible. The point of the script was to clean up invoices from historic customers
light turtle
all good
edgy oxide
Does that help with anything?
light turtle
I misunderstood something that's why
basically you likely had something saying "please mark subscriptions as unpaid" a long time ago
then you switched this to automatically cancel
so when you void, it maybe respects that, and on my account I kept "unpaid"
let me try the same flow you had again after I change the setting, I should see unpaid -> canceled too then
edgy oxide
I believe these are the setting you are reffering too?
light turtle
yes, mine on the Subscription status still said "unpaid"
booh I still get unpaid -> active
but I think it's because Test Clocks ignore those settings
Okay at this point I got nothing. Can you contact our support team on https://support.stripe.com/contact/email (use the contact form, not chat). Mention my name and let me know once you have sent the message
I'll get someone on my team to work with the product team to figure out
1/ What is the expected behaviour
2/ Why did one subscription end up with a different behaviour
light turtle
All good Im sorry I got nowhere 😦