#hillct_best-practices

1 messages · Page 1 of 1 (latest)

plain pantherBOT
#

👋 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/1445156246700429405

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

reef moss
#

Hi there 👋 no, just providing a bank account via Financial Connections is not sufficient. Stripe has strict regulatory and compliance requirements, which fluctuate per region, that we must adhere to. This typically means we need some information when bringing entities into our ecosystem. That's why the Global Payouts flow still shows how to create recipient accounts and onboard them.

cerulean saddle
#

I understand KYC, but why is data from the Financial Connections link not being used ot populate even the basic KYC fields like name, address and the related identity information from the account identity fields. In our case specifically, the KYC form asks for website, whih in every case for our customers is a page on our website I would expect we could easily pre-populate. The form itself discusses of course, privacy policy and TOS requirements, which in all cases will be our documents to that effect. I guess I just haven't seen a workflow that is sufficiently frictionless, that would cause our developer customers to prefer direct payments into their bank account, versis something like Paypal, which is obviously low rent, so not prefereble from our standpoint, but the vast majority of the KYC questions are geared toward corporate customers, which ours are not. Is there a way to pre-populate some of the fields while continuing to utilize the stripe embedded KYC forms rather than building our own?

reef moss
#

Yup, I'm fairly certain you can provide the information you've already collected when creating the recipient Account. Are you having trouble doing so?

cerulean saddle
#

this is the issue. I haven't been able to identify a sufficiently frictionless (from our customer's standpoint) workflow that correctly integrates the connected account (step 1 in our flow) with the custom connected account that is generated, This might be a timple token exchange step I'm missing, but my issues were precicitated by over the weekend, seeing that the 'known good' linked bank account was still coming up restricted in the sandbox enviroment, and so on. These issues might have been red herrings as today I see that the financial connection is marked active and the connected account is marked Enabled. Still, the workflow for our customers is unduly arduous, so if there's a way to pre-populate some fields (even if the users is prompted to review/edit them) in the KYC interview, that would be very helpful, (I haven't found a way to do this) and if you could point me to a more complete workflow for linking the account identified via financial connections, as the external acount with regard to the Connected stripe account, that would be very helpful

reef moss
#

the connected account (step 1 in our flow) with the custom connected account that is generated
Wait, why are you creating more than one Connected Account?

cerulean saddle
#

Maybe this is a misunderstanding on my part. My goal is to prompt for the financial connection account workflow, get the account token, then as i understand it I need to then initiate the Stripe Connected account workflow so our customer (payee) has a stripe accouhnt with which to connect the Financial connections account token as the external payee acount

reef moss
#

Nope, that doesn't sound right.

#

Financial Connections is just for collecting bank account info by letting people log into their online banking portal, in a way similar to what Plaid provides.

It can be part of Connect Onboarding, but usually isn't the beginning of the flow if so.

cerulean saddle
#

This then is the crux of my confusion. Once I prompt for a financial connection, what workflow is needed to enable pay out to that account?

reef moss
#

Wait, are you doing Connect, or are you doing Global Payouts?

cerulean saddle
#

We looked at Plaid which does offer a transfer product now, competing with Stripe. Their integration went without a hitch. The only reason why I'm trying to do it via Stripe is because Plaid doesn't offer incoming payments via credit card. In our case, we recognie that the overton window is such that users are more comfortable making payments via credit card so we need to offer that option, but for those users also offering services on our platform we need the ability to pay them. My goal in coming back to Stripe was to avoid having to deal with multiple vendors in handling financial transactions

cerulean saddle
reef moss
#

A V2 Account is required, they're more linked to V2 APIs than Connect. Similar concepts though.

cerulean saddle
#

Again, maybe I misunderstood. I've been around a while, from back when stripe connect was just essentially a per-transaction revenue sharing mechanism, so maybe I've misunderstood the new architecture

reef moss
#

I think you're a bit turned around, and I'm struggling to understand how best to help straighten that out.

Just looking at the Global Payouts flow, where are you seeing it recommended that you incorporate Financial Connections? I assumed that would be the default flow if you used our hosted onboarding.

Are you using "Financial Connections" and "Financial Accounts" interchangably?

cerulean saddle
#

Ultimately, we just want to perform global payouts using as frictionless a woerkflow as we can, from the perspective of our users. Can you point me to the proper documentation and workflow? I guess i didn't understand the V2 account mechqanisms

reef moss
cerulean saddle
#

I guess I am using Financial connections and linked account interchangably. I'm trying not to misuse Stripe Connected Account in a confusing way. To me a Stripe onnected account is the old style Stripe Connect

reef moss
#

Wait, linked account is yet another thing

cerulean saddle
#

yeah, that's where I started with global payouts

reef moss
#

Yup, how far did you get? Where did you see Financial Connections?

cerulean saddle
#

As a mechanism to validate accounts, so that we can get the data needed to complete a global payout. Again, trying to minimize friction for our customers

#

I have ro run an erend. How long are these threads left active? Back in maybe 30 minutes

#

I have financial connections inking an account and (I guess because I misunderstood) I have the KYC data collection via the embedded form, for a stripe connected accountr working. I guess I don't need the latter, or need v2 of it, or something

plain pantherBOT
reef moss
#

What section of the guide is that from, and what does this mean?

I have financial connections inking an account

cerulean saddle
#

I'm able to prompt the user to complete the financial connections workflow such that I get a tokenized account back. My assumption was I would then use that token to either pay the account or connect it to some other stripe component that would allow me to pay out to that account

neon crown
#

👋 Hi, Toby Needs to run, just getting caught up here.

#

I see some mention of a few different products including Connect, Global Payouts, and Financial connections, but it's not entirely clear what the end goal is here.

Connect and Global Payouts effectively handle different scenarios, one isn't a replacement for the other.

I think you might want to review this guide to determine which makes more sense for your use case.
https://docs.stripe.com/global-payouts/compare-with-connect#compare-global-payouts-and-connect-payouts

There is no need to separately collect financial details. The hosted connect onboarding process should allow the user to provide financial details. You can even specify it as a requirement.

cerulean saddle
#

I just got back myself

#

Having reviewed the document you indicted, we need to use global payouts. The closest analogy to our use case is affiliate payments, but more importantly, we need a decoupled solution because some of our users will be making payments incoming to us, for services, while other of our users (providers) will need to receive payouts and the two classes of user do not nessecerily overlap

cerulean saddle
#

It looks like this may have been the key information I needed (with regard to required data collection) https://docs.stripe.com/global-payouts/api-recipient-creation
Where the documenteation discusses 'Stripe hosted forms" with regard to global payouts recipient creation, ate those embedded elements similar to the Stripe Card Element(s) used in the payments product? or are they rendered at a stripe.com URL to which the user is redirected? https://docs.stripe.com/global-payouts/recipient-creation-options

Create a Global Payout recipient with the API

Learn how to onboard recipients for Global Payouts using the Stripe API.

Create recipients

Learn how to create recipients to accept Global Payouts.

neon crown
#

This wouldn't be an embeddable element like (card-element/payment-elemetn, etc) but it's own hosted page on Stripes domain.

cerulean saddle
#

Looking now at the API based local data collection option, why would compliane changes require integration changes? Are there anticipated compliance changes other than "You must collect this field of data, that must be submitted as this property" ?

#

I'm not trying to reate more work for myself, but at the same time, I want a seemless user experience. Based on payee location, doesn't the API just generate a list of data fields to be collected, in a parsable format so I can simply generate the needed UI elements?

#

looks like that's what happens, but if you could point me to the API docs specifically related to that response (required kyc fields for collection) that'd be helpful, as I'm not seeing it at this moment

neon crown
#

Sorry not completely following the question

cerulean saddle
#

Assuming I go forward with internally collecting the compliance data, it sounds as though the recipient creation API will provide me the list of fields required for collection. With regard to the compliance data. Is that accurate? Where is that further documented?

neon crown
cerulean saddle
#

And am I correct in assuming that a V2 stripe user object is applicable for both payments via CC and payouts provided the required additional account detail?

#

Or in this context would my users have one or the other stripe accounts or both in some cases?

#

My concern here is that I may have been using the V1 API for my initial CC incoming payments implementation, not really recognizing that the payments functionality was only available in V2

#

At this point, I'm just trying to determine how much of my current integration I need to rewrite

neon crown
cerulean saddle
#

Excellent! This of course means that I'm going to have to re-implement my stripeUser Mongoose extension but that's my problem, and I guess update my CC payments integration accordingly. Accordingly. Ultimately, I guess this is a good problem to have and I feel like I've made progress, although I'm not in front of my computer so we will find out how much actual progress, tomorrow. Thanks for your help! And Toby as well!

neon crown
#

Of course! I'll let Toby know 🙂

cerulean saddle
#

Oh separately, and I guess I could open another thread to discuss this, but it will be helpful if the stripe mCP server owth tokens had a longer expiry than 5 minutes. Unfortunately. Most of the oauth host applications in my case gemini-cli don't properly renew tokens in the appropriate time frame

plain pantherBOT