LibbySwanger - test clock

[vestal current]

Hello, as Pain said some things will trigger slightly after the timestamp you'd expect them to. If that doesn't work I can look in to the specific invoice if you send me the ID

[half gate]

You may also want to check your settings,

[tepid jetty]

Oh! What settings should I check?

[half gate]

Just a moment whilst I get the link

https://dashboard.stripe.com/settings/billing/automatic

Check the Manage failed payments

You should have a retry schedule in there with a few settings

[tepid jetty]

@vestal current the invoice ID is in_1LEFjYCKdFRIRRTEGz3Et3yc

[vestal current]

Thank you. Will check in to that ID in a minute

[half gate]

These are my settings for my subscriptions.

I believe they're set differently originally, it will keep trying to charge?

[vestal current]

And yes check that setting if you have "leave subscription as is" that may be the cause

[tepid jetty]

If the subscription is set to send invoice rather than charge automatically, does this setting have an effect?

[half gate]

That's something you will have to change if you want to cancel the subscription once payment fails

[half gate]

I believe this goes back to your settings too

[tepid jetty]

We have it set to "mark the subscription as unpaid"

[half gate]

You will need to set up this to match your flow

What about retry schedule?

[tepid jetty]

Custom retry schedule.

However, I have not made an attempt to pay the invoice. I've been trying to confirm what happens when the subscription is past due.

[half gate]

When the subscription is past due it will create a charge

[tepid jetty]

Ahhh I see!

[half gate]

It should charge the default payment method

[tepid jetty]

Even if the account is invoiced?

[half gate]

I believe there is an event sent when the subscription is past due

I cannot recall entirely, Pompey may know better.

[tepid jetty]

Yes, that is the 'customer.subscription.updated' event

[half gate]

But if I'm not wrong, it should fall back on the account settings for subscriptions.

[tepid jetty]

The issue is that the subscription is not being marked past due, so it's not being updated.

[half gate]

That's weird, let me try it on my end.

You used the email invoice to customer correct?

[tepid jetty]

Yes

[half gate]

My status was set to overdue

The invoice is incomplete

and subscription status was set to overdue

When you created the subscription, how many days did you put for the invoice?

The payment due

[tepid jetty]

30 days, but also, I have my settings marked to "leave invoice as-is" when all payment retries fail. I've updated that to mark invoice as uncollectible. I'll advance time and see if that changes anything.

[half gate]

Yes,

I set mine to a day just for testing, and you need to have the setting

as that updates the invoice

also the status did change to past_due

[tepid jetty]

I still have the invoice marked as open

[half gate]

Yes, I believe that's the status it will have

as mine is the same

then a new draft invoice should be generated

[tepid jetty]

I'm confused - why would a new draft invoice be generated?

[half gate]

for the next payment

[tepid jetty]

Ohh I see

[tepid jetty]

But what I'm trying to understand is why an open invoice due July 31, when the test clock time is in September, isn't causing the subscription to be marked past due.

[half gate]

I believe the invoice isn't part of the clock

If you open the invoice link up you will see, it states "due in x days"

instead of saying "past due"

but the status should change

[half gate]

Scroll down and click payment page

Since that isn't part of the testclock, I'm not too sure

[tepid jetty]

Ahhhhhhhhh

I see!

So it's possible that I won't be able to test this aspect of the integration using test clocks.

[half gate]

You should be receiving events though

[tepid jetty]

I am receiving events, yes

[half gate]

One of them should return the past_due status

Just to clarify, I'm not a staff member or anything; just another Stripe consumer. This is mainly from my knowledge so I may be wrong.

[tepid jetty]

Thank you for the clarification! I really appreciate you helping out.

[vestal current]

Yeah sorry the server has been busy and it has been hard to keep up with this thread. Where are we now with this?

[half gate]

The testclocks do not update the invoice status as it seems they do not actually impact them (based on the settings at least).

But they do reflect onto the subscription.

[tepid jetty]

@vestal current I've tweaked my subscription settings so that after retry attempts are exhausted, the invoice is marked as uncollectible. I've advanced the test clock time by a minute a few times. The subscription is still active instead of past_due.

[half gate]

It still does not set the status to past_due?

[tepid jetty]

Nope.

[half gate]

Hmm, those are my settings and it does do that.

Are you advancing by 30 days?

[vestal current]

Can you send the ID of this latest subscription as well?

[tepid jetty]

sub_1LEDxJCKdFRIRRTEvTo8ATvj

[vestal current]

Thank you. I have asked for help from a colleague on looking in to this one so we should have a better idea of what is going on soon

[tepid jetty]

Thank you!!!

[half gate]

Alright so I've tested it and the issue is the amount of days you have set the invoice to

You need to advance by 30 days (or however many you have set) not a few

[tepid jetty]

The invoice is already well past due though - its due date is July 31 and the test clock date is Sept 6

[half gate]

Hmm, let me try to go past mine.

I'll have to create another subscription since I can only advance 1 day at the time currently, moment.

[sand brook]

Ok stepping in here to look

Are you ever attempting payment on the invoice?

[tepid jetty]

No

The subscription is set to "send invoice" rather than "charge automatically" so no attempts are made

[half gate]

Just to clarify, mine are being kept open too even though it's past the date which leads me to believe the test clock isn't simulating that part of the invoice.

But I'm looking at past invoices which were generated the same, they're marked as uncollectible or failed (which were not simulated).

Not sure if that's entirely the problem.

[tepid jetty]

on invoice statuses - if the subscription is set to send_invoice instead of charge_automatically, the invoice remains open even once the due date has elapsed. Once a configured amount of time has elapsed, the invoice is set to uncollectible to reflect that we assume the customer will not or cannot pay the invoice.

But once the invoice due date has elapsed, the subscription should be marked past_due.

[half gate]

I just tested with 10 days, for me it did set the subscription as "overdue" and status past_due

What I can see is that you already paid October

Can you try making a new subscription with 1 day payment then simulating forward a day

Because I believe that subscriptions renewal is now in November

[half gate]

This should set it as past due

[sand brook]

Invoice status will still be "open" after the due_date unless you've specified otherwise here:

[tepid jetty]

but the subscription should still be getting marked past due, shouldn't it?

[half gate]

You already paid October

Judging by the image you sent

[tepid jetty]

Yes but there is also an invoice on the account that is past due.

[half gate]

That does not matter as you’ve paid an invoice that’s recent

Which set it back to active

Check the subscription the date should’ve been updated

[sand brook]

"That does not matter as you’ve paid an invoice that’s recent"

Yep

[tepid jetty]

Whoa, really?

[half gate]

It’s the same as if you were to renew the subscription in a way, was scratching my head for a second on why it wouldn’t set it to overdue

[tepid jetty]

Just to make sure I understand the flow -

• invoice is issued and goes unpaid
• we pause service on our end because of the unpaid invoice
• subscription is still billed monthly, so an invoice of $0 is issued (because we have paused service) and is marked paid (because it is $0)
• subscription is set back to active because the most recent invoice is paid

[half gate]

I believe you have it confused with another flow

Where you would still generate invoices but stop the service if they're unpaid?

And you must clear all invoices to receive your service

[sand brook]

@tepid jetty What exact behavior are you looking to achieve? Can provide a recommendation from there

[half gate]

What stripe does is, it will generate a new invoice for the time and that has to be paid. Once that is paid the subscription will resume.

[tepid jetty]

Is there a way to put the subscription on hold so it does not automatically issue monthly invoices?

[sand brook]

It sounds like you might need: https://stripe.com/docs/billing/subscriptions/pause

[tepid jetty]

Yes!

Perfect!!!

Thank you!

[sand brook]

Recommend reading thoroughly to understand caveats

[tepid jetty]

Oh wait, this is not quite it.

[half gate]

You also need to understand that stripe already "pauses" the subscription in a way when an invoice is unpaid (with the settings you have in place).

It wont renew until the invoice is paid, it does this automatically.

I understand what you are trying to do, but you are looking at it as if they need to pay every single invoice which is not the case.

[sand brook]

That section above is particularly important

If none of those are your use case

Then cancelling the sub is probably the way to go

[tepid jetty]

What happened with the account i sent a screenshot of:

1. issued an invoice
2. advanced the test clock until the invoice was past due.
3. this also meant advancing the test clock until a new invoice was issued. however, our subscription is per usage, and I hadn't applied any usage, so the new issued invoice was $0.
4. because the new invoice was for $0, the account was never marked past due.

[sand brook]

Yes that's correct

[tepid jetty]

Ok! This is really helpful info, thank you!

[half gate]

From what I can tell, the invoices aren't being marked as uncollectible with the test clocks.

[tepid jetty]

Sounds like you're right and canceling the subscription would be needed, I'll check in with our product folks and see how they want to proceed.

[sand brook]

What do your account settings look like for invoice behavior?

[half gate]

These are the settings

It does set the invoice as uncollectible normally as I do have some already (from previous testing).

[sand brook]

No what does it say here:

[half gate]

moment

I believe you're looking at requiring confirmation settings

[tepid jetty]

@sand brook where would I find that setting? I'm having trouble

[half gate]

But I have those settings as follows

[half gate]

Scroll down a bit, half way through the page.

[tepid jetty]

@half gate I think they are asking about my settings

[half gate]

Under manage payments that require confirmation

[sand brook]

No was asking @half gate since they are reporting a bug

[half gate]

Actually, I may be wrong give me a moment

since I did not use the invoice payment method

I used a saved method instead

I'm assuming you'd have to change the Manage invoices sent to customers settings instead.

[tepid jetty]

Okay just making sure - my issue is all resolved, if the most recent invoice is paid, the subscription will remain active, even if there is a previous invoice that went unpaid and is past due

Is that correct?

[half gate]

Yeah, seems like that's what you need to change instead as it has specific settings for manual invoice payments.

[sand brook]

Yeah that's correct. I screenshotted the wrong section. Whoops

[half gate]

@tepid jetty Scroll down to the Manage invoices sent to customers section and change it accordingly

The first settings I believe would apply to saved payments option

[sand brook]

@tepid jetty You are correct. Recommendation from my end is to cancel the subscription and change the settings Pain mentioned

[half gate]

Seems like you'd need to upgrade to invoicing plus if you want to change the flow more

(Since you want to cancel the invoices quicker) the options above only allow after 30 (min) days

[tepid jetty]

Really just getting the subscription to past_due is all we need, and I understand how that works now. Thank you!