#coner-murphy_webhooks

1 messages Ā· Page 1 of 1 (latest)

scarlet nacelleBOT
#

šŸ‘‹ 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/1481278829799673989

šŸ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

verbal heath
#

Hi šŸ‘‹ did you create the destination to listen for Events from your own Account or from your Connected/V2 Accounts?

If you did the latter, can you try again doing the former

storm jetty
#

It was configured using the latter as weā€™re using connected accounts in our product so figured we needed that one.

Also, I assumed as weā€™re creating V2 accounts in the code weā€™d need that one?

I can try using the other option but will that still work with connected accounts?

verbal heath
#

If you're creating v2 Accounts, and are listening for the v2.core.account* Event types, I'm pretty sure those Events are emitted within the context of your own Account.

If you're not creating v2 Accounts, then I wouldn't expect v2 Account Events to be triggering.

storm jetty
#

Ah okay, so if we wanted to use thin events for both the v2 account creation and for events on connected accounts weā€™d need 2 webhook destinations? One for our own account and one for the connected accounts/v2 accounts?

#

This probably ties into a separate question I have which is what is the correct flow for onboarding accounts into connect now?

I can see in the docs that OAuth is not recommended for new connect platforms / marked as legacy. So Iā€™m assuming we shouldnā€™t use that route and instead should create new standard accounts either v1 or v2 in the context of our connect client and have the user finish onboarding that new account?

Is it no longer recommended for users to onboard an existing account they have into a new connect platform?

verbal heath
#

That is correct, we no longer recommend the OAuth flow since introducing our Platform Controls. You can run into some odd/frustrating behavior if you try to onboard an account that is already fully controlled by another platform.

There are actually three ways to create a Connected Account now šŸ˜…
The most legacy way is to create an Account object and specify the type when doing so. Those are our Standard, Express, Custom Connected Accounts.

#

Now you can also create an Account using the controller hash, which gives you a bit more control over the structure/behavior of the connected account.

And then v2 accounts are our newest version, and the upside to those is that they're intended to be used as both a Connected Account and a Customer within your Platform.

#

Which one you need to create exactly will fluctuate a bit with which integration path you want to follow/best fits your needs, and what level of access the owners of your connected accounts should have to their own accounts.

storm jetty
#

Okay thanks for clarifying.

So, how it sounds is we shouldnā€™t support OAuth as an onboarding route. Weā€™re currently creating V1 accounts with the controller config. Previously was using the type property set to standard but migrated to the controller config.

Long term I think we will migrate to V2 accounts for the benefit you outlined with the account/customer setup.

This is why Iā€™ve been experimenting with the thin events now as the V2 account events use them. I presume eventually all events will be sent this way?

Do you think Iā€™ll need the 2 destinations to get this working?

verbal heath
#

I do think you'll need two destinations here, probably. One listening to Events from your Platfrom and one listening for Events from your Connected Accounts.

It's a little hard to say for sure without specifically knowing what Event types you're after (and honestly I haven't played around with v2 too much myself yet so even then I may be a little unsure), but I think it's a pretty safe assumption to make.

storm jetty
#

Currently weā€™d need the v2.core.accounts* events. Specifically the requirements and identity events.

#

Iā€™ll experiment with having two destinations, one for the platform and one for the connected accounts.

verbal heath
#

I think all of those Event types would be thrown to your Platform destination, but may be mistaken

storm jetty
#

Ah yes I imagine so. I imagine weā€™ll only need the connected accounts destinations when other events are migrated to thin events like the subscription events?

#

For now weā€™ll just the need the platform one.

verbal heath
#

Yeah, like if you're creating Subscriptions on your Connected Accounts, then their customer.subscription.* related Events should get surfaced to the Connected Account's destination.

storm jetty
#

Yeah makes sense. But, theyā€™re not available as thin events yet are they? I think I just saw the account ones and some billing ones available as thin events currently?

verbal heath
#

That's correct

storm jetty
#

So our setup would be the subscription events using the older snapshot style to our existing webhook and then the v2 events using thin events going to a new destination.

Then as the subscription events move over to thin events we can create a new destination using thin events for the connected account events?

verbal heath
#

I'm not confident all of the existing Subscription related Events will get ported to thin Events.

storm jetty
#

Oh? I thought thin events was considered the next version of webhook events and eventually the older snapshot style was going to be marked legacy

verbal heath
#

From what I'm seeing they're being released in parity with new features that are relying on them. For instance v2 Account Events are introduced alongisde the new v2 Account object type. The Billing related Events are associated with our newer Billing Meters, which are designed to be higher throughput than previous Usage Records.

#

I haven't noticed any Event types moved to thin Events just for the sake of making them available as a thin Event yet

storm jetty
#

Okay that makes sense. Do you know if there are any plans to migrate them over for parity?

verbal heath
#

Oh hm, but I just noticed report run Events are in the v2 space as well šŸ¤”

#

Not that I've heard of so far

#

Ah, because v2 Report Runs are a thing, more for me to catch up on šŸ˜…

storm jetty
#

Thanks, Iā€™ll look at trying out the platform stuff for V2 accounts but weā€™ll probably stay on V1 for a bit I imagine.

#

Just to confirm on the connect onboarding stuff.

  • donā€™t use OAuth as itā€™s considered legacy.
  • create either v1 accounts with controller hash or v2 accounts connected to the connect client ID
#

Choosing between v1 and v2 is based on your own needs but both are current?

verbal heath
#

Yup, exactly!

v2 will be better if you need to also treat your Connected Accounts as Customers, but it's still pretty new so it isn't my default recommendation yet.

storm jetty
#

Makes sense. We do currently do that where the accounts we create may potential purchase from us. So maybe V2 is better for us long term.

#

Just to check if we create accounts v1 or v2 with full dashboard access, should they get access to the usual stripe dashboard? Not an express version?

verbal heath
#

Yup

storm jetty
#

Thanks and if users want to they can delete the account from within their stripe dashboard. We canā€™t use accounts.del with those accounts as theyā€™re full dashboard accounts with stripe as the responsible party for losses etc?

verbal heath
#

That's right

scarlet nacelleBOT
storm jetty
#

Just to confirm changing to listening to the platform account events fixes it and I can see the events again on the endpoint.

#

Sorry separate question. I just noticed in the Stripe connect dashboard for V2 accounts it says ā€œYou canā€™t remove v2 accounts with access to the standard dashboard from your account. Please reach out to supportā€

Whatā€™s the correct way to remove a connected account if the user wants to leave the platform?

wide canopy
#

Hi toby had to step away so I'm taking over

#

My understanding is if the connect account has dashboard access, they would disconnect themself

#

I'm not sure what capabilities we provide for you to be able to initiate this yourself if they have dashboard access

#

But if this is something you need I do recommend writing in to support to see if it's possible to enable this

storm jetty
#

Ah okay thatā€™s fine, I just wanted to check what the situation was. We donā€™t need the support currently as long as we know they can do it via their dashboard

#

As I assumed theyā€™re connected accounts but I guess theyā€™re not as we create them as standard accounts with full dashboard access. So itā€™s just a usual Stripe account that is pre connected to our connect instance

#

But they could disconnect and use it as a normal account?

#

Also separate question I just want to confirm. Since OAuth is no longer recommended, there is no way to onboard an existing stripe account into a connect platform? You need to create a new account and have it onboarded by them but they can reuse business details when they onboard?

wide canopy
#

there is no way to onboard an existing stripe account into a connect platform?
Oauth is the only way, but yeah the recommended current flow is to not re-use accounts

#

It's to create new ones and use legal entity sharing

#

But they could disconnect and use it as a normal account?
I'm actually not sure off the top of my head whether or not this is true for v2 accounts

storm jetty
#

Okay thatā€™s what I thought. Thanks for confirming that. The legal entity sharing is the prompt that comes up on the onboarding flow asking if they want to reuse business details?

#

Is it true for V1 accounts?

wide canopy
wide canopy
#

I actually do recommend you reach out to support based on that error message

#

To get confirmation on how to do this in your v2 setup

storm jetty
wide canopy
#

Actually looks like all newly created accounts have this enabled by default according to that

#

And with platform controls: If you prefer to disconnect your account from the platform instead, reach out to the platform. Your platform will be able to initiate the disconnection process for you.

#

So idk why you can't disconnect this account

#

Probably has to do with the v2 configuration

#

But that's why I recommend you get clarity from support on this

storm jetty
#

Okay will chat with them about it.

#

Unrelated is there a webhook event that gets fired when a connected account transitions from restricted to enabled?

#

For both V1 and V2 accounts

wide canopy
#

Not one specifically for that

#

You'd have to listen to account.updated

#

And check the requirements hash, charges_enabled param, payouts_enabled param, etc

storm jetty
#

What about for V2 events? The top level updated event doesnā€™t seem to get fired. It seems to be just the more specific ones like requirements, etc.

#

What would you recommend I check if I wanted to update a status in my own DB to try keep it to mirror Stripes status for the connected account?

wide canopy
#

There's not a single field to determine this unfortunately

#

You have to inspect the outstanding requirements

storm jetty
#

I assumed it would be that event. But, when I request the related account from that event, even though the account shows as restricted in the dashboard, the requirements returned on the account is empty.

wide canopy
#

Can you share the account id?

storm jetty
#

acct_1T9ocB3bk46XaGf5

#

Itā€™s just a new V2 account Iā€™ve created and when Iā€™ve fetched the requirements from the account it shows as the entries as empty. Iā€™ve made sure to include requirements in the request.

wide canopy
#

I see outstanding requirements on that account so not sure why you wouldn't be getting any back

#

Can you share the request id?

storm jetty
#

req_v2nE0keSxsSv0lqW7

#

Ah sorry thatā€™s a different request for a different account.

#

One second

#

Hereā€™s the correct one: req_v2dFVckt8EVyDa9KV

wide canopy
#

I'll check some logs

#

But also we can't see response bodies for get requests

#

So would you be able to paste what you are getting back in here?

scarlet nacelleBOT
quick dust
#

hi! taking over for codename_duchess, catching up still but feel free to drop the response like they requeseted when you're able

storm jetty
#

Here is the call Iā€™m making in the code and then the requirements and identity objects

  const account = await stripe.v2.core.accounts.retrieve(
    event.related_object.id,
    { include: ['requirements', 'future_requirements', 'identity'] }
  );---

{
requirements: { entries: [], summary: null },
future_requirements: { entries: [], minimum_transition_date: null, summary: null },
identity: {
attestations: {
directorship_declaration: null,
ownership_declaration: null,
persons_provided: [Object],
representative_declaration: null,
terms_of_service: [Object]
},
business_details: {
address: null,
annual_revenue: null,
documents: null,
estimated_worker_count: null,
id_numbers: [],
monthly_estimated_revenue: null,
phone: null,
registered_name: 'tetst',
registration_date: null,
script_addresses: null,
script_names: null,
structure: null
},
country: 'US',
entity_type: 'company',
individual: null
},
id: 'acct_1T9ocB3bk46XaGf5'
}

quick dust
#

oooooh i see

#

hmmmmmm

#

just for fun can you try once more and only include requirements, not the other properties?

storm jetty
#

Same issue, same reply for requirements and entries being just []

quick dust
#

hmm ok, give me a bit longer to poke at this but then we might need to convert this to an email case so i can dig in deeper.

storm jetty
#

Sounds good, let me know what needs to happen

quick dust
#

can you try once more and explicitly pass 2026-02-25.clover in your API call?

quick dust
#

also what happens if you try to create a direct charge on that connected account?

storm jetty
#

If I try pass apiVersion in that SDK call I get a TS error saying that property doesnā€™t exist.

#

I can create subscriptions and take payments via that account

#

In sandbox that is

#

Thatā€™s without going through the onboarding flow at all. Just creating the account with the below call.

    Const stripeAccount = await stripe.v2.core.accounts.create({
        contact_email: data.emailAddress,
        dashboard: 'full',
        identity: { country: 'US', entity_type: 'company', business_details: { registered_name: currentOrg.name } },
        configuration: { merchant: {}, customer: {} },
        defaults: { responsibilities: { fees_collector: 'stripe', losses_collector: 'stripe' } },
        include: ['identity']
    });
quick dust
#

ok cool, let me try reproducing that way real quick

#

ok i'm seeing something similar with that account configuration

#

still testing some things

scarlet nacelleBOT
sick pilot
#

Hi there - I'll be taking over for solanum here

#

just getting caught up

#

If you update your creation call to include a real configuration for the account as a merchant or customer - defining the dashboard access and loss liability and all that, I expect you'll see requirements populated in the response

#

So we're kind of just creating a shell for you here, but we agree this is a bit confusing and we're going to talk to the product team about it.

Maybe we can do something like putting something in requirements that lets you know that you haven't configured the account yet, or somethign like that

storm jetty
#

That would be good. Iā€™ll try define more in the customer and merchant configuration tomorrow.

Just to check it can have both canā€™t it? Weā€™d want the account to be able to process subscription payments from its own customers as well as be a customer of our platform account.

Should you be able to take subscription payments when the account is in this status of not being fully configured? As I managed to make a subscription with it fine. Or, is this just because itā€™s in a sandbox account?

sick pilot
#

Yeah, it absolutely can be both, that's why we provide both properties.

This is the most fundamental difference in v1 vs v2 Accounts

#

As to the last point; I'm not sure. You're using it as a Customer in that case so it is somewhat reasonable.