#Apk
loud sigil
Setting is up in the GUI it asks me to choose between Listen to: Events on your account, or Events on Connected Accounts.
I want to capture both things that happen on my platform account as well as things that happen on the connected accounts
hard galleon
You need 2 separate webhook endpoints then
1 for platform and 1 for connect
So you can receive both
loud sigil
What API version should I choose? I am developing this for the first time, so wouldn't it be preferable to use the latest?
hard galleon
Yeah use the latest if this is all a new integration
Is your account on the latest version?
Recommend using the same version as your account's default really
loud sigil
Not sure what version my account is set to use
Is the latest version supported by SDK's like the .NET SDK?
hard galleon
Is the latest version supported by SDK's like the .NET SDK?
it is
You can check your default here: https://dashboard.stripe.com/developers
Will be at the bottom and have a default badge next to it
loud sigil
Ah I see, thanks!
hard galleon
No problem
loud sigil
Are the webhooks for the platform account and connected account structurally the same?
I am looking to consume them from the same endpoint URL... I assume they will show the corresponding accountID in them?
The API docs make it sound like if they come in from the platform account they will not have any account ID on them, is that accurate?
hard galleon
You will run into issues doing that because you won't get the event payload until you've verified the webhook signature and extracted the event payload
Recommend at least passing a url query param to differentiate between connect events and platform events if you have to use the same endpoint
That way you know which signing secret to use
loud sigil
When I create a connected account, send the user to the link, and wait for them to finish filling everything out, is that when the "account created" webhook triggers or is it a different one?
hard galleon
There isn't an account created webhook
loud sigil
So then I just need to listen to account.updated, correct?
hard galleon
What are you trying to do?
Although I think the above are only applicable for standard accounts
So if you're only creating standard accounts, then above should be sufficient
loud sigil
What are you trying to do?
Onboard new standard connect accounts. Just don't want to rely on the user signing up to hit my "success" return URL to process that their account has been set up correctly
hard galleon
Got it
loud sigil
So I'd instead listen for a webhook to confirm it worked
It seems like account.updated would show this
hard galleon
account.updated will be fine
loud sigil
Would account.application.authorized do the same thing and only fire when their account is successfully set up?
That way I'm not getting spammed account.updated for other things they change that I don't care about?
hard galleon
This event occurs when a connected account connects to your platform.
So yeah you'll get less events if you use that
loud sigil
```This event occurs when a connected account connects to your platform.```
Where'd you see this specific chunk of text?
Cause for account.application.authorized I see
Occurs whenever a user authorizes an application. Sent to the related application only.
hard galleon
tiny dawnBOT
loud sigil
One last weird webhook question... when I want users to pay, I am creating checkout sessions for them to pay on the Stripe-hosted checkout page.
When they successfully pay, would I expect to see
checkout.session.completed
or just
charge.succeeeded
or both??
noble zenith
You will see both, and payment_intent.succeeded for that matter (assuming it isn't an asynchronous payment method that will make the intent go in to a pending status first)
You can just have your server listen to whichever one makes the most sense for you
loud sigil
Which of those 3 would be the most reliable to know that the payment method was accepted and processed properly?
noble zenith
All three of them are reliable so it depends on what exactly you are looking for. Are you using any payment methods like bank debits that will take time to process?
loud sigil
I am letting the connected standard accounts accept whatever payment methods they choose. I expect 90% of them to just be normal credit card payments, but I'm sure some others will be mixed in like ACH or Affirm.
Most of my clients are car dealerships (service departments) so they could be charging customers anywhere from a few bucks to thousands. I expect them to want to offer payment plans.
noble zenith
Thanks for the clarification. So here checkout.session.completed would let you know that they have submitted their payment details but ACH payments can fail after that point (the bank can take multiple days to process them).
So it would likely make the most sense to listen for payment_intent.succeeded as that will only trigger when the payment is successful and the bank is sending over funds. You will also want to listen to payment_intent.processing events so that you can be aware of when a payment has started but needs time to see whether it will succeed or fail.
I would recommend reading through this doc, it goes in to more detail about checking the status of Checkout Payments https://stripe.com/docs/payments/checkout/fulfill-orders
loud sigil
So even if the charge is something slower like ACH or Affirm where it may take time to process, I can still rely on "payment_intent.succeeded" or "payment_intent.payment_failed" to come across at some point?
AKA those webhooks are good indicators or success or failure regardless of payment method?
noble zenith
Correct, those will always happen eventually when you try to confirm the payment intent
loud sigil
Only thing that's confusing then is the doc you just linked to me says I should be looking at *"checkout.session.asyc_payment_failed" *and *"checkout.session.async_payment_succeeded" *and doesn't mention the paymen_intent events at all, so it isn't 100% clear which of the two types of events/webhooks I should rely on
I understand that the doc says those async ones are for "delayed" payment methods that take time to process, but are they also sent for simple credit card charges?
And is there any real reason to use them over payment_intent ones?
noble zenith
My apologies, I was not aware of those events. Those should serve the same purpose. No specific reason to use one event over the other. It is basically a tradeoff of more information on the Checkout Session vs more information on the PaymentIntent but you can always look up whatever is missing via the API anyways.
loud sigil
I suppose one reason to use "payment_intent.succeeded" or "payment_intent.payment_failed" would be if I have to create a subscription for someone...
From what I see the checkout.session ones are just for the initial/single charge and I don't think those would be sent for a subscription charge from subsequent months
noble zenith
Correct, in that case you would only get a session completed event after the first payment. You can listen to payment_intent.succeeded or invoice.paid events for the payments after. Again same tradeoff, Invoice event will initially have more info on the invoice and subscription but you can also look it up from the payment intent event if need be
tiny dawnBOT
loud sigil
I'm adding one set of these webhooks for the platform account, and a separate set for connected accounts.
Would only the platform account need the events for
account.application.authorized
and
account.application.deathorized
or should both have it?