#becca-subscription-events
1 messages ยท Page 1 of 1 (latest)
You can do it that way
we basically went down that road and then revisited the documentation and saw it said to use invoice.paid and got concerned
but no concerns or warnings on doing it that way?
So invoice.paid generally is preferred I believe because that way you get a notice of success/failure with each invoice of the sub
If all you're trying to do is tell when it's active, then customer.subscription.updated is fine
my next thing is to listed to an event (probs invoice.paid? but haven't fully researched) so that we can show a banner for the user to go to the portal and resolve an issue, so might be adding that event anyway, but still seems easier to customer.subscription.updated just for the "this user is subscribed to x and that expires on y" part yeah
one other question, in reading the chat, I've seen lots of mentions of the payment_behavior for a subscription and it being suggested to change that from allow_incomplete to default_incomplete. we're using checkout with the prebuilt form, and it doesn't seem like that field is accessible in the checkout payload?
What's your usecase for changing it?
it's been a recommendation a lot in here to switch, so I was looking at the docs for it. not sure I fully understand the differences between the values yet so not sure I need to, but in looking into it I noticed I'm not seeing it in the .net lib params (or I'm overlooking which nested object it's under)
now I just have FOMO ๐ no really, just trying to understand what it is / how it works and it seemed odd that it's not on the call that I can tell
Usually you'd change that param to handle more customized flows or alter how you'd handle authentication on a payment. But since Checkout is a hosted flow, everything is handled for you. If you need a more customized flow, I recommend using Elements instead
ah, ok. no so far so we seem to be good with the hosted flow (and certainly prefer it that way), just can be a bit confusing as to what applies where
becca-subscription-events
thanks!
sorry to hijack the thread, but i was having similar issues today, and actually using only customer.subscription.updated doesn't handle the case in which the subscription is created with an initial free trial, so you need to handle customer.subscription.created for supporting that scenario
(in the testing environment this is not reflected for some reason, because an update is always triggered at the end, but in prod is not the case, only created is triggered)
events are different between environments? that doesn't seem right?
I don't wanna add confusion, since might not be actually related, but this was my experience today
I will take the reply of @upbeat pier as the source of truth but might be worth at least testing it
Events work the same in Live and Test mode
would be best to ask in chan maybe, but I would guess maybe the created had the status of active already since there was no payment and that's why no updated event, but that wouldn't explain environment differences
Yes i will open a new thread for this, since might be useful for others
cool, appreciate the potential heads up though for just handling updated!
@gloomy portal did you have more questions?
I guess it's related to the other thread too but maybe just confirmation that my guess ^^ is on target? other than that, no
Yeah so mostly ignore that other thread. I read what my colleague told you and it's correct
hmm. it seems like in the other thread that updated firing in test is the odd-man-out, meaning for a free trial it wouldn't fire, but in here that would mean that the update event couldn't be relied on for creation. so now I'm just confused ๐ sorry
ignore that thread
so customer.subscription.updated will always fire even if a subscription is started with a trial?
yes