#itaied-connect-webhook

1 messages · Page 1 of 1 (latest)

mild shard
#

Hello, I assume you mean in your webhook handler?

blissful brook
#

Yes

mild shard
blissful brook
#

Great thanks!

blissful brook
#

There is something I don't understand.
I'm trying to run it locally using stripe listen --forward-to localhost, but the account field is not attached.
Following the link you sent me, I tried with stripe listen --forward-connect-to localhost and the request is not proxied.
How can I make sure the account field is attached?

mild shard
#

Can you share the ID of an Event you're expecting to see?

blissful brook
#

payment_intent.created id is evt_3LDT4ABGvIZrJ02319ULpDNH

mild shard
#

How are you triggering that event?

blissful brook
#

Filling the checkout session in test mode

blissful brook
#

?

#

I have already attached the on_behalf_of as well

viral jackal
#

Hello ynoj had to step out and I am catching up. Apologies for the wait this server has been pretty busy

#

Do you know which account your CLI is logged in as?

#

It looks like we sent that event to your CLI and you should see the account on it as long as it goes to the connect version of the webhook

blissful brook
#

we don't see the account field in the dashboard events as well

#

I'm logged in as the platform account

viral jackal
#

The event that evt_3LDT4ABGvIZrJ02319ULpDNH is for, acct_1KtYssBGvIZrJ023, is the platform account correct?

blissful brook
#

Yes this is the platform account.
Where can I see that?
I had attached the on_behalf_of header so I expect the account to be the connected account

viral jackal
#

on_behalf_of charges still happen on the platform account, they create other events on the connected account, but the payment intent events will all be on the platform

#

And the way you can see the connected account is by checking the destination or on_behalf_of parameters on the payment intent

blissful brook
#

Is there any other way to group the events by?
This is our problem: we have many environments that need to receive the events. We thought about writing a proxy service that will receive the events and proxy them to the corresponding service. By knowing the connected account id I can identify the environment. The actions we are doing, such as checkout, refund, etc., are adding the on_behalf_of attribute to mark the related environment (connected account id of the env). The environment data is written on the connected account metadata and we are trying to read that metadata in the proxy service (from the event acc)

viral jackal
#

Is there a reason you can't still use the connected account ID here? That data should still be available just in a different place.

blissful brook
#

what do you mean?
In this event evt_3LDT4ABGvIZrJ02319ULpDNH I don't have the connected account id:

  id: 'evt_3LDT4ABGvIZrJ02319ULpDNH',
  object: 'event',
  api_version: '2020-08-27',
  created: 1655902434,
  data: {
    object: {
      id: 'pi_3LDT4ABGvIZrJ02311z2PxLZ',
      object: 'payment_intent',
      amount: 3000,
      amount_capturable: 0,
      amount_details: [Object],
      amount_received: 0,
      application: null,
...
#

Oh you mean that we should read it from on_behalf_of, right?
If so, I need a consistent way that will be correct for every event (for example, refunds, created account, amount capturable etc)

viral jackal
#

I meant that if you are more interested in which connected account this is associated with, you can check the payment intent's on_behalf_of parameter at event.data.object.on_behalf_of

#

"on_behalf_of": "acct_1L5OpqBFEp1HvtXU",

blissful brook
#

Is there a single place I can set metadata for all of the objects created by the library?
Something like new Stripe("secret-key", { metadata: { key: value } }) like the stripeAccount

storm mesa
#

Hello 👋
I don't think there's a way to set metadata globally, no

blissful brook
#

mm.. that's may be a big problem for us.
Do you know if there's another field / header we can use globally?
I need to setup the client with that header so that every event will contain it, this way I can identify from which client the event has originated

storm mesa
#

I don't think there's one field as such
let me think if there's a workaround here

storm mesa
#

yeah not seeing any alternatives