gracine - envs

[gritty torrent]

If you need more than 2 envs (test and prod) it's recommended you create multiple Stripe accounts

[clear tulip]

I see, so if we have a dedicated QA env, I should use the "production" mode on this account ?

the test mode would be irrelevant

[gritty torrent]

No the live mode in stripe is only for live payments. It's against our TOS to test with it

[clear tulip]

ok so the test mode in each "fake" env

i see

thank you

[gritty torrent]

No problem

[clear tulip]

I would have another question, after experimentation with recuring billing and testing different failing scnenarios, is there a clear documentation somewhere that would explain how the subscription from active -> past_due -> cancelled/unpaid states are expected to change through time

From what I tested, it seems that the past_due state only changes 3 days past the period_end

But i don't see where this is specified

[gritty torrent]

You can configure that behavior in your settings: https://dashboard.stripe.com/settings/billing/automatic

[clear tulip]

yeah i saw that

Its configured in this manner

If my subscription.period_end is 09-09-2022, I advance my test clock to 1 month later (10-09-2022)

If my subscription.period_end is 09-09-2022, I advance my test clock to 1 month later (10-09-2022)

• if the payment fails, it will take 3 days for the subscription to because past_due => this is not something i configured anywhere

[gritty torrent]

Oh I think I misunderstood your question initially

You just want to know why active -> past_due took 3 days?

[clear tulip]

yes

understand the state change flow for QA / Test Cases expectations

[gritty torrent]

Gotcha. Can you share an invoice or subscription id where you saw this happen?

[clear tulip]

yes hold on

in_1LgBQVKvSpF2Fmo2gbSORaSB

[honest idol]

Sorry for the delay! My colleague had to step away so I'm catching up and digging into the invoice you shared.

[clear tulip]

all good thanks

the question basically starts at the 3:13 comment

[honest idol]

I found the subscription change from active to past_due

[clear tulip]

ok

My question is actually to understand exactly the business logic when the state is expected to change

so we can understand and write our Test Cases accordingly

[honest idol]

I'm trying to follow the sequence of events. I see a payment attempt was made on July 11, which failed. The test clock was advanced to July 18 after this.

[clear tulip]

actually, the test itself is not that important

To clear things up, my exact question is : I would like to understand the state change workflow when the subscription.period_end is reached and the credit card is not present or expired

because we are testing with test clocks and its not quite clear to us

[honest idol]

to be clear, there's subscription.current_period_end but no subscription.period_end. is this what you're referring to?

if a subscription is created with collection_method=charge_automatically, it becomes past_due if a charge fails. the next status change depends on whether the max number of retries has been reached (based on your billing settings)

[clear tulip]

ah, yes sorry current_period_end

ok so if collection_method=charge_automatically and I advance my test clock 1 day after subscription.current_period_end and the subscription state is 'active' its a bug with the simulation ?

I do not specify collection_method explicitly

but it should default to that

as per documentation

I have to go, I will check your answer when I will be back, thank you