#bucknermr - Subscription Workflow

1 messages · Page 1 of 1 (latest)

fleet shoal
#

Hi 👋 I'm checking on this

hard imp
#

Thank you!

fleet shoal
#

Do you a subscription ID for two of these subscriptions? One that behaved how you expected and one that is misbehaving now?

hard imp
#

Here's one that is behaving strangely: sub_JZlhEsHwxGjyVA

#

Here is the event that shows the status moving from "past_due" to "active": evt_1KHdeiIaPuvbLLAKkH5RgNDy

#

It claims the source of the event is this api request: req_4svlyShiIBebVQ

#

I am looking back to find one that was behaving as expected...

naive flicker
#

Thank you for the IDs checking in to them...

#

Do a custom retry schedule, delete any retries in it, and set "subscription status" to mark the subscription as unpaid

#

Then do your steps 1 and 2 again and the subscription will go to unpaid

hard imp
#

I'm not sure I understand the expected behavior here, we are not voiding any invoices

naive flicker
#

Yeah looks like I may have misunderstood a bit of what was happening here. Did you find a subscription that behaved as you expected?

hard imp
#

Ah it looks like I was confused. So we do have the rule to set subscriptions to "unpaid" if all retries fail, and we also have a rule to set invoices to "uncollectible" if all retries fail. So I was seeing that happen simultaneously when the automatic retries failed, but it looks like every time I tried to manually trigger this (by setting the invoice to uncollectible), the subscription would instead get set to "active".

#

I think I see the workaround is to use custom retry and remove all retry attempts. However, I would like to understand the behavior I'm seeing. I don't understand why setting the invoice to uncollectible should update the subscription status to "active"

#

As marking as uncollectible is not the same as voiding an invoice

#

Here's the settings we have on our account:

unknown.png
naive flicker
#

And when I did your flow I saw the invoice go to unpaid but my settings leave the invoice as is

unknown.png
#

But yes that is strange that uncollectable would override us marking the other setting that sets the subscription as unpaid.

#

Still looking

hard imp
#

Thanks for looking into this. Regarding this:

If the invoice is in a paid or uncollectible state, the subscription state is set to active
The heading for that section is "Voiding an invoice generated by a subscription". The way I read that is, if you void an invoice that is currently in the paid or uncollectible state, the subscription status is set to "active". However, I am not voiding any invoices during this workflow.

naive flicker
#

That came from us because of your subscription settings but that is why it is marked as uncollectible

hard imp
#

Yup that's a request I made from the cli. What I don't get is why that would change the subscription status to "active". Voiding is a different action from marking uncollectible

naive flicker
#

Marking uncollectible itself is expected to change the subscription to active

hard imp
#

Why is that? & is this documented?

#

The docs you have linked to are for voiding an invoice

hard imp
#

Also, I'm unable to use the workaround of removing the automatic retry attempts, as it seems like the Test environment mirrors the Live environment. When I remove the custom retry attempts, it removes them from livemode as well 😬

#

Is there any other way to simulate the auto-retry fails?

#

Thanks again, and sorry for bombarding you with so many questions!

naive flicker
#

Sorry I dropped off this a bit.

#

Looking in to all of that.

#

I confused those settings with other ones that can differ between live and test, apologies for suggesting changing them in a way that would impact live.

hard imp
#

No worries, I thought that might be the case so I double checked right away, no harm done 👍

naive flicker
#

Good to hear. I've reached out to some colleagues on how to get an unpaid invoice for testing and will look further in to the uncollectible behavior

#

So unfortunately there isn't a great way to get an unpaid invoice without going through the retries now. The suggestion for right now would be to create a separate account to test this on

hard imp
#

Gotcha, thanks. I am gonna sign up for the billing clocks beta. Let me know if you get more info on what's happening with the uncollectible behavior thankyou

naive flicker
#

So I heard back from my colleague. Marking marking the invoice as uncollectible will not trigger what is at the end of the retry logic. The only thing that will do that is all of the retries actually happening (even if there are 0 of them). The automatic retry logic watches the status of the latest invoice on the subscription and manually marking it as uncollectible tells us that you don't expect the user to be able to make payment on the invoice so we don't retry payments on it any more.

#

I was wrong on what I said about marking it collectible earlier so let me clear that up as well. This is these are the docs I should have linked https://stripe.com/docs/revenue-recognition/methodology/subscriptions-and-invoicing#uncollectible-invoices

When an invoice is marked as uncollectible, we clear the accounts receivable account since we no longer expect payment.
Parts of the revenue for the invoice might have already been recognized. Upon marking it uncollectible, the recognized revenue is offset by contra revenue in the bad debt account.
Parts of the revenue for the invoice might still be deferred. Upon marking it uncollectible, the remaining deferred revenue is cleared.
https://stripe.com/docs/billing/subscriptions/pause#free
If you want to offer your services for free, update the subscription’s pause_collection[behavior] to mark_uncollectible.
All invoices generated before the resumes_at date are immediately marked as uncollectible. Stripe won’t send any upcoming invoice emails or webhooks for these invoices and the subscription’s status remains unchanged.