#neils_666
brisk sand
Your integration shouldn't ever rely on events coming in in order. See: https://stripe.com/docs/webhooks#event-ordering
tribal peak
that says we should 'handle delivery accordingly.' - any more help on that please?
brisk sand
Depends on what you're trying to do. What are you storing in your db with these events and why?
tribal peak
just that there is an active subscription until end date
we receive the create and update events at basically the same time
and the create event has status 'incomplete' (correctly). If we happen to end up with that one recorded then the customer doesn't get access they paid for.
brisk sand
Ah yeah
That's why my colleague suggested invoice.paid
Why does the hour delay matter?
tribal peak
The previous period reaches its end, so the customer will lose access at that point. At that point you update the subscription and send me a new end date, all good. But don't send me the invoice.paid for an hour. So if I was ignoring the subscription.update event and relying on invoice.paid the customer would not have access for that hour.
brisk sand
Why do you need to listen to subscription.updated at all though?
You can just rely on invoice.paid
and invoice.payment_failed
tribal peak
When I receive them I need to expand the subscription to get the end date for the new period. At the end of the new period I will block the customer's access until I receive a new invoice.paid from you which means customer won't have access for an hour.
brisk sand
But you can just retireve subscription by id when you get the invoice.paid event and do it then
No need for subscription.updated event
If you get invoice.payment_failed then you can block access
tribal peak
but I don't receive invoice.paid for an hour
see the sub rolled over at 13:07, but the invoice wasn't paid until 14:07
tribal peak
because the sub's end time was 13:06
tribal peak
we store the current subscription end date and give the customer access until that time is reached. If the subscription continues and the user pays then you call a webhook to tell us the new end date and we store that, so they get access for another period.
If that last webhook call is delayed then the customer goes without access for however long that delay is.
brisk sand
But why do you need to rely on the exact timestamps for provisioning access? Is it the nature of the service/product you're offering? Because most people don't do that when building subscription integrations. Most people use invoice.paid to allow access and don't strictly provision access based on the date window. Then, if payment fails, they get invoice.payment_failed and they can block access if they want. However, most don't block access until subscription is cancelled (which you can automate if a certain number of payment retries fail).
tribal peak
Giving users access for the precise subscription period they've paid for seemed like the correct and fair thing to do, and if they have a payment issue they need to sort out it seems correct and fair to disable their access until they make that payment.
Your subscription feature's events provide the info needed to do that and it's been straightforward to implement.
Assuming that a customer has paid forever until we receive a webhook from you saying that they haven't seems... potentially unreliable.
I missed the docs telling me to do it that way.
I could add 1 hour to the subscription end date we store - that would allow the customer access until the invoice.paid arrives?
brisk sand
You could do it that way if you want
pastel basinBOT
brisk sand
If you need to restrict it to the exact timestamps it's a bit tricky but that's fair way to handle it
But if you're going to do that. I don't see why you couldn't just rely on invoice.paid and invoice.payment_failed + retrieving the subscription in those events
tribal peak
Thanks. Is invoice.paid always sent 1 hour after the subscription rolls over, or could it be longer? (assuming payment is taken ok)
brisk sand
It won't be exact
But should be approximately 1 hour
Invoices are always finalized after 1 hour w/ subscriptions
tribal peak
ok thanks.
Why do you update the subscription with a new start/end period before the customer has paid?
brisk sand
Well after the previous period ends, the subscription needs a new starting period
That will be the case regardless if payment was successful
And subscriptions are pretty powerful. Not everyone wants their sub to cancel after an incomplete payment
There's plenty of folks that let subs still advnace billing periods with unpaid invoices