#jskitz-events
vale flame
Hi there, there is no explicit guide. There are a lot of events but they all have subtle differences so it really depends on your use-case for what you want to listen for.
A lot do have overlapping information.
And no, data is not expanded by default
If you need the data expanded then you have to retrieve that object after receiving the webhook
I'm happy to help recommend some events if you tell me more about your use-case.
tulip whale
why does customer.updated have subscriptions expanded?
vale flame
customer.updated provides a customer object which includes information about Subscriptions by default.
Actually that's wrong
I don't think you should be seeing the expanded field for subs in customer.updated
Do you have an example event ID I can look at for that?
vale flame
Ah okay so the event body you see in the Dashboard is a bit different.
That will show the entire expanded body
But the Webhook will not
tulip whale
I got this from stripe cli exporting json
so, that is also showing expanded view but the webhook won't see that?
I'm using the --format JSON flag, and it's spitting out expanded views of whatever comes in
vale flame
Hmm I am looking at the CLI webhook internally and see the same. I haven't played with the --format JSON flag but that may be doing it. I can promise you we won't expand it for standard webhooks. We note this in our docs here: https://stripe.com/docs/expand#with-webhooks
--format JSON or --print-json?
tulip whale
okay, I can test and good to know that, because it's a ton of information. On the customer.created and customer.updated webhooks, will there be something in the "minimal" version that has changed?
I'm using the CLI like this
stripe listen --forward-to localhost:4242/webhook --format JSON
I can log whatever I get from the web app to make sure that what is coming in is not expanded version, although I do think that this would be confusing to have these be different if stripe CLI is doing something different.
vale flame
Yeah I'm surprised that CLI is expanding so I'm looking further into that.
Agree that is confusing to not mirror expected webhook behavior
Can you clarify what you mean by the "minimal" version?
You just mean the non-expanded version?
tulip whale
minimal meaning not auto expanded... yeah totally
vale flame
Gotcha. And you are seeing both of those events emitted on customer creation?
tulip whale
but I think the main thing I'd love to hear, is just your recommendations on what I should respond to. I have a single subscription product, a python backend, I can send emails but also might allow Stripe to do it. I'm using Checkout instead of Elements. I keep a cached version of Products, Prices, Customers, Subscriptions. Would like to respond to failures or at least know they happen.
I've mostly been following this - https://stripe.com/docs/billing/subscriptions/overview#subscription-events
Here are all the events I get now for a success
event checkout.session.completed
event charge.succeeded
event payment_method.attached
event customer.created
event customer.updated
event invoice.created
event invoice.finalized
event customer.subscription.created
event invoice.updated
event customer.subscription.updated
event invoice.paid
event invoice.payment_succeeded
event payment_intent.succeeded
event payment_intent.created
just seems to be a lot of overlap
In a lot of the Stripe sample projects, seems like they consider success after checkout.session.completed
but seems like payment can still fail after that
or 3DS required, etc
vale flame
Gotcha so for the initial payment and starting the Sub you just need checkout.session.completed. That will signal that a Sub was started successfully. After that it depends a bit on what you want, but most people just track the Sub status via customer.subscription.updated. If that status moves to past_due or canceled then you take actions.
tulip whale
oh yeah? it's as simple as that? I didn't know that checkout.session.completed meant payment is successful and I can authorize the product.
some where in the docs, I saw the minimal number of webhooks... maybe it was in designing an integration
and maybe I should also monitor customer.subscription.updated because I'm caching subscriptions
mellow river
Hello, 👋 , I'm stepping in for bismark who has to step out soon.
Yes, the checkout.session.completed event means that the first payment was successful, Checkout will handle any 3DS auth or payment failures with the customer. The session is completed after the successful payment
Looking at that doc and catching up with the other requirements that you have mentioned...
tulip whale
okay cool. I see I still get the events even on failure, but yes that once that process is completed, I will get the checkout.session.completed, so that's nifty.
Seems to me I should listen to
checkout.session.completed
customer.updated
customer.subscription.updated
invoice.paid
invoice.payment_failed
also, I want to keep some information on default payment method to show in the interface... not sure what event I would get that from
mellow river
Those all sounds like fine events to listen to, do you have anything in specific where you aren't sure what event to listen to?
There are two places to store that on a Customer, let me find the docs
tulip whale
looks like the charge object has it?
if I listened to charge.succeeded perhaps?
or I can expand default_source on customer perhaps?
mellow river
You can also set it in invoice_settings.default_payment_method https://stripe.com/docs/api/customers/object#customer_object-invoice_settings-default_payment_method
tulip whale
so basically after a successful payment, I could make another call to expand that?
mellow river
I don't think Checkout automatically sets it on either, you would have to make a separate API call to set it in one of those fields. invoice_settings.default_payment_method is the canonical one
I think it will be set as the default PM on the subscription. Are you seeing anything on that object?
tulip whale
I see it on charge.succeeded on the property payment_method_details
I also see it on payment_method.attached
mellow river
Yep, so you can use either of those to set that payment method as the default wherever you want.
The main distinction is setting it on the Subscription vs the Customer. If you set it on the customer, it will be the default for all subscriptions but you can override that by setting the default payment mehtod on the subscription
tulip whale
okay cool, so to recap, I will implement these
checkout.session.completed
customer.updated
customer.subscription.updated
invoice.paid
invoice.payment_failed
charge.succeeded or payment_method.attached, and I should get everything I need I believe
okay, right... so if I get it from the Customer, it's the default for all subscriptions.
okay, well I think the above will give me a pretty good start and then I'll just have to see what I encounter and go from there