#heka6
tiny tendon
The customer.subscription.updated should work as far as I know. I am a but unclear on what you observed when testing this. For scenario #1, your subscription was active even though the first payment failed?
Do you have the ID for the subscription that you saw this on (sub_123)
jagged elk
Well using the clock feature, the subscription was active for few seconds before going to past_due
and then even when payment is successful, then subscription is active, but I have no way to confirm that payment is taken via the invoice because the invoice stays as draft for some time before getting updated
let me check an ID
tiny tendon
Gotcha, testing this myself with a test clock to see what you can do
jagged elk
thanks. Actually I canceled the subs...
I need to recreate the use case to provide you with an id
lethal notchBOT
hearty ocean
👋 stepping in as Pompey needed to step away
Let me know when you have an example and I'd be happy to look
jagged elk
Sure
but I wonder if it is not better if you generate on you side using the clock. because the issue is in the chain of events as when payment fail I had:
trialing>active (during one minute)>past_due
let me see
you will see the list
hearty ocean
Can you give me the Sub ID you tested with?
jagged elk
it just went to active afterv a failed payment
but I don't even see the payment intent yet
if I move the clock, it will appear and change the sub to past_due
hearty ocean
Right because the Invoice hasn't finalized yet.
So what I would recommend doing here is that you instead just attempt payment of the Invoice immediately.
So if you receive a customer.subscription.updated Event and the status changes from trialing to active then you hit /pay (https://stripe.com/docs/api/invoices/pay)
That will trigger payment and then you can handle the outcome
jagged elk
yes but from a webhook in prod? What is the most efficient to ensure, subscription is paid for the first time successfully and active
?
hearty ocean
Yes you would use a webhook like I said above if you are worried about the 1 hour finalization period after a trial ends.
By calling the /pay API yourself you would "remove" that 1 hour waiting period
jagged elk
ah. ok
got it
what do you think about listening to the invoice updates and check subscriptions associated. Do you agree it is heavier?
or would that be ok
?
hearty ocean
What do you mean by "listen to the invoice updates"?
jagged elk
webhook event invoice.payment_succeeded
then get the sub_id
then chgeck what I need to check
hearty ocean
Oh you mean wait until you receive that Event to actually provision your product?
hearty ocean
Yeah I wouldn't do that because you will have to listen to every single one of those for every renewal
And check the Sub each time
jagged elk
but listening to customer.subscripion.updated I get all updates to no?
hearty ocean
With my method above you are only taking action based on specific properties/values in customer.subsription.updated
jagged elk
not sure I get then your method. let me check again
hearty ocean
You would basically have an if statement that checks if the previous_attributes contains status: trialing
jagged elk
then force the pay, and base on the status act
hearty ocean
Yep
hearty ocean
If payment fails then it would still go through the normal retry schedule, yes.
jagged elk
I fear with this I will not intercept the successful ones after the retries. I will still have the delay issue and possible mismatch between subscription status and invoice status
ok but I got the point
thanks a lot
not straight forward use case
just wanted to be sure I was not making things more complicated than needed...
hearty ocean
Not sure what you mean by:
I fear with this I will not intercept the successful ones after the retries. I will still have the delay issue and possible mismatch between subscription status and invoice status
Once the initial payment fails the Subscription will move to a status of past_due
Then on a successful retry it would move to active
hearty ocean
👍
jagged elk
Thanks a lot