#floki_v2-event

1 messages · Page 1 of 1 (latest)

clever bluffBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1494025696052510731

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

tight pine
#

floki_v2-event

#

👋 @winter crane this id is a v2 Event and those work differently from v1 Events which can be confusing if you are familiar with the old way

v2 Events related to a connected account (v2 Account) are sent to the platform's own WebhookEndpoint and not the one configured for connected accounts.
It's really confusing for a lot of developers right now and my team has flagged the feedback for months 🙁

So my guess is that you have one WebhookEndpoint that listens to v2 Events on connected accounts and you forgot to add the one that listens to Events on your own account

winter crane
#

I actually have two webhooks setup, one for "regular" v1 events and another for v2 events

Screenshot_2026-04-15_at_14.31.04.png
tight pine
#

yes but that's the mixup I was explaining

winter crane
#

In the events tab I see a bunch of v2

Screenshot_2026-04-15_at_14.32.01.png
tight pine
#

the top one only listens to Events on connected accounts and the one you gave me is on your own account

#

Try creating a third one that listens to those v2 Events on your account

winter crane
#

The one I gave you, you mean the second one?

#

I'm not sure I'm following.. what destination should I set the third one ?

tight pine
#

Create a new one, pick "your account" (the left option) and pick the v2 Account related Event.

winter crane
#

And what url destination should I choose?

tight pine
#

You would enter the URL where you want to receive those Events in your code

#

I'm just trying to show you how it works so that you can receive those Events. Once you see it and it "clicks" you'll then be able to send the Event to the right part of your code to handle it

winter crane
#

Ok, just created it

tight pine
#

yep I see it. Now create a new v2 Account and you'll see that endpoint gets the Event you wanted

winter crane
#

I do see the event in deliveries now

#

So you are saying that I need to create a webhook for connected, and another one with same events for "your account"?

#

What does the "destination" do for Connected webhooks though?

tight pine
#

😓

#

This is really confusing unfortunately. My team keeps explaining this to users as it's not intuitive especially when you deal with both v1 and v2 Events that work subtly differently

#

The gist of it is that:
Anything you create on your account goes to your account's endpoint. For v1 it's a customer.created or payment_intent.succeeded. But for v2, we also have all the v2 Accounts Events that go there too as you created that v2 Account on your platform so v2.core.account[configuration.merchant].capability_status_updated and such. The reason is because v2 Accounts can model the same thing as v1 Customers too that you just charge.

Anything that happens inside a connected account goes to the "connected and v2 accounts" one. Like a Payout on that v1 or v2 Account for example

#

I'm sure it makes limited sense. I have a jira internally where it took 3 months for it to even click for me and I help design our APIs.

It all makes sense in isolation when you look at only v2. But it doesn't make sense in a world where you handle both (which everyone has to do)

winter crane
#

Anything that happens inside a connected account goes to the "connected and v2 accounts" one

If this is the case, why can't the webhook send these events to my destination? That way I can differentiate a payment_intent.succeeded from a customer subscribing to my application from my customer receiving payment - I wonder how will I be able to do this with this third webhook if I have to listen to payment_intent.succeeded event

#

I'm still confused by the relationship between the "connected and v2 accounts" and "your account" - do I need both listening to the same v2 events and the connected will route to "your account" one which will ultimetely send to its destination? Meaning the destination doesn't matter for "connected and v2 accounts" ?

tight pine
#

yes you need both

#

I'm sorry I know it's confusing. But the way it's designed: you call the POST /v2/core/accounts, you create that account on your own platform the same way you create a PaymentIntent or a Customer. So Events related to that object itself would go to your own platform.
v2.core.account.created is similar to customer.created conceptually

But a Payout that happens on that v2 Account (from its balance in Stripe to its bank account on file outside of Stripe) would create a payout.created inside that "compartment" and so that one would go to your "connected and v2 accounts" endpoint

winter crane
#

For the "connected and v2 accounts" webhook I can't tick the payout_created for example

Screenshot_2026-04-15_at_14.57.12.png
tight pine
#

it's hard to say with a truncated screenshot, can you share the full page?
My guess is you are editing an existing endpoint that listens to Thin Events which isn't compatible with v1 Events

winter crane
#

You're right.. so looks like I can't have a webhook that processed thin (v2) and snapshot

tight pine
#

correct you can't

#

when you do this in the UI the first time it creates 2 separate endpoints

#

I don't want to over-apologize but we know it's confusing (and my team really lives this pain all day right now)

winter crane
#

What I'm getting is, I need 3 webhooks:

  1. Events from "connected and v2 accounts" that listens to v2 thin events - destination doesn't matter
  2. Events from "your account" that listens to v2 thin events - destination matters
  3. Events from "your account" that listens to regular v1 snapshot events - destination matters
#

Is this accurate?

Also, things like payment_intent.created will always go to the 3 webhook, be it from my account or connected account?

#

If yes, how do I differentiate if that payment_intent was under context of my own account or third party, connected accounts?

tight pine
#

Honestly you likely need a 4th

Events from "connected and v2 accounts" that listens to v1 events

winter crane
#

What fourth?

#

I'm almost switching to polling for connected accounts LOL

#

Oops, yeah I see you referenced some text

tight pine
#

sorry I quoted your framing and tweaked it

#

you basically want

  1. all v1 Events for what happens on your own account (PaymentIntent, Charge, your own Payout, etc.)
  2. all v2 Events for what happens on your own account (v2 Account creation/update Events)
  3. all v1 Events for what happens inside connected accounts (Payouts for example)
  4. all v2 Events for what happens inside connected accounts (any v2 API that you use on those. Say one day when we ship v2 Payouts for example)
winter crane
#

But events from connected account are not sent to the destination, hence all this thread - correct?

#

So they all go through "your account" equivalent - yes?

tight pine
#

no

#

only the specific v2.core.account.* ones aren't sent

winter crane
#

Gotcha

tight pine
#

Does it make some kind of sense now (separate from whether you feel like we should have built it this way)?

#

I'm going to share this whole convo with the product team in charge of this design since it hopefully make them see how confusing this is

winter crane
#

I don't fully understand why, but seems like only v1 events from connected are sent to the destination, and v2 are sent to the platform and gets routed into "your account" webhook

#

But maybe I still don't get it.. just answer me this: does destination matter for v2 "connected" webhook?

tight pine
#

yes it does 😓

#

sorry you say the word "destination" and I've never really seen it used like this before so I'm also struggling to grasp your own summary which doesn't help you 🙁

winter crane
#

Destination would be the URL the event gets sent to

tight pine
#

oh boy okay

winter crane
tight pine
#

sorry we keep changing fundamental words all the time in the Dashboard to not match the API and it's also the bane of my existence

#

so really destination means nothing to us. It's a URL you configure, we send it where you tell us to send it.

winter crane
#

Yes, but that's the source of all this.. initially I had the "connected and v2 accounts" webhook setup to send v2.accounts.* events to my URL which was never doing so.. then you told me to create a "your account" webhook with those same v2.accounts.* events and it worked

#

That's why I'm asking, does it even matter the URL I put in the "connected and v2 accounts" webhook that listens to v2.accounts.* events?

clever bluffBOT
tight pine
#

😓

#

The URL matters, it points to your own code. If you put https://example.com then we send the Event(s) there

#

So you need to decide what your code does and how you handle each flavour of Event and then put the right URL in each endpoint

#

Some people might have one URL and then dynamically decide what to do based on the Event type they receive (v1 or v2, on the platform or inside a connected account)
Some people will have 4 separate endpoints with a different URL each
That part is definitely up to you

winter crane
#

That's how I setup everything.. but "Connected and v2 accounts" had 0 events delivered (even 0 attempted)

#

Which was my first screenshot

#

Oops, I didn't send this screenshot - but yeah, no event was ever attempted to be delivered on that

#

Then you told me, create a "your account" webhook listening for the same events and boom, event delivered

#

So that's why I'm super confused if the first "Connected and v2 accounts" webhook URL even matters.. event deliveries are only through the "your account" anyway (at least for v2.accounts.*)

tight pine
#

there are 4 types of things that can happen

  1. Any v1 Event for objects created on your own account (Customer, PaymentIntent, Subscription, etc.). Those go to the "your account" flavour of the endpoint. You had that
  2. Any v1 Event for objects created inside any of your connected accounts (v1 or v2) such as a Payout, or a PaymentIntent if you were to use the Direct Charges flow. Those go to the "connected and v2 accounts" endpoints.
  3. Any v2 Events for objects created on your own account. Today this solely applies to v2 Accounts objects. Those v2 Events go to the "your account" flavour of the endpoint. You did not have that one. That's the one I made you created.
  4. Any v2 Events for v2 objects created inside any of your connected accounts. An example would be a v2 BillingAlert for example. Those go to the "connected and v2 accounts" endpoints. You had that but you were looking for the wrong event in it
winter crane
#

Why does onboarding a customer as Connected account sends events through "your account" webhook?

#

When they are adding data for onboarding, all these events are created in "your account" webhook

tardy nebula
#

hi there, I'm taking over for koopajah as they had to step away. It was sent to the "your account" webhook because that was an action that your account took on an object that was created on your account

winter crane
#

Hello

#

How is that an action that my account took, the workflow is that I create a connected account and the onboarding is all done through the .js library

#

All actions such as providing documents and data are done through the user of my application

#

On the connected account that belongs to them

#

I'm not changing my address for my account, rather they are changing their address for their connected account

tardy nebula
#

because the user is operating on the v2 account object that you created

winter crane
#

Is this not how I should do it?

tardy nebula
#

no, you're doing it correctly. you should just expect the events to appear in the "Your account" webhook, like my colleague said

winter crane
#

What about when they generate payment (payment intent?!), since I created that account, does it also go to "your account" webhook?

#

And does this mean I don't even need a "connected and v2 accounts" webhook then?

tardy nebula
#

that would depend on how the Payment Intent is created. if it's created on the connected account (like if you were using the Direct charges flow) it'd be in the "connected and v2 accounts" endpoint. if it's being created on your own account (like if you're doing Destination charges) it'd be in the "your account" endpoint

winter crane
#

I'm using payment intent service:

var service = new PaymentIntentService();
var paymentIntent = await service.CreateAsync(options, new RequestOptions
{
  ApiKey = stripeSettings.SecretKey,
  StripeAccount = externalAccountId,
  IdempotencyKey = ...
}, cancellationToken);
#

With the connected account id

tardy nebula
#

yes, that is using the Direct charges flow. since you're providing the StripeAccount parameter, the PaymentIntent is created on the connected account

winter crane
#

so that will go through my "connected and v2 accounts" webhook

tardy nebula
#

correct

winter crane
#

In the end, do I even need a "connected and v2 accounts" webhook listening to thin v2.accounts.* events since these account objects are created from my account and this events go to "your account" one?

tardy nebula
#

Any v2 Events for v2 objects created inside any of your connected accounts. An example would be a v2 BillingAlert for example. Those go to the "connected and v2 accounts" endpoints. You had that but you were looking for the wrong event in it

you would only need one for the scenario my colleague described here. if your integration isn't doing that, then no, you don't need one

winter crane
#

Gotcha, I'll try to update things here and see how it goes

#

Appreciate the help and send my regards to you colleague, they were super helpful and understanding 🙏

tardy nebula
#

you're welcome, and I'll be sure to pass that along 🙂