#mike_best-practices

1 messages · Page 1 of 1 (latest)

elder mesaBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1249666605881757707

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

cosmic oxide
strong ermine
#

Do I understand correctly we should send the vendor's billing information to every checkout_session or payment_intent?

cosmic oxide
#

no, it's just set on the Account object representing the vendor.

strong ermine
#

wait - I am reading the docs and I don't understand it. What I undestand is that we send vendor's id to on_behalf_of but how can we save the vendor's billing information to their connected account?

cosmic oxide
#

ow can we save the vendor's billing information to their connected account?
it's collected during the onboarding and/or they enter it in their Dashboard , depending on what type of account (Standard/Express/Custom) the connected account is.

strong ermine
#

Ok, so if this is just the information from the connected account (the vendor's account) how can they (the vendor) can utilize previously stored information in our system during the onboarding and connecting their account to our account?

cosmic oxide
#

are they Custom accounts?

#

if so you'd just pass that address info you have to that API field mentioned above when creating the Account object

strong ermine
#

well, this is something we (probably) need to dig deeper to understand it better. We have just the connect process done. To my understanding we can only connect to a vendor's account not to have a control over its creation, right?

cosmic oxide
#

I'm not sure what your second sentence means sorry

strong ermine
#

Ok, let's go step-by-step. The vendor (seller) would register on our platform and next add a stripe payment provider (our feature) to connect their account to our account. clear so far?

cosmic oxide
#

well usually, no, they create a new Stripe account for use with your platform, they don't connect existing ones.

strong ermine
#

I see, so they literally cannot connect their existing account? I don't mind - just want to know

#

if there is a new account can we create this account on their behalf and fill in all necessary data to it (based on previous registration on our platform)?

cosmic oxide
cosmic oxide
strong ermine
#

Ok. We definitely appreciate less development effort on our side, so if we rely on the Standard or Express accounts how can be sure that the minimum information is collected (such as for the taxes) to be working correctly? As to our understanding we have developed collection of minimum suggested location info (us=zip codes/full address in some states, canada=province and the rest of the world just country). Can we somehow set minimum required information for the onboarding process or this can be done only with Custom accounts?

cosmic oxide
#

I mean our onboarding (Stripe\AccountLink::create) always collects the minimum information needed, it wouldn't be useful if it didn't 🙂

#

there's a lot more than just address needed , see https://stripe.com/docs/connect/required-verification-information

ultimately what I suggest you do is do some testing in test mode, create Accounts and onboard them (https://docs.stripe.com/connect/testing#identity-verification) , do some example payments in the flow that you're looking to use , and look at how the receipts come out (https://docs.stripe.com/receipts?payment-ui=direct-api#manually-send-receipts-from-dashboard); using the API/product that way is the only way to really get a good grasp on this

elder mesaBOT
strong ermine
#

we will definitely run through the whole process however we would like to have the data in our app complaint with the data stored by the vendor during onboarding. We can (of course) do it after the creation of the account however would it be possible somehow to send "expected address" to the account creation to avoid repeating the same information on our platform and in Stripe account?

odd jolt
#

Hey! Taking over for my colleague. Let me catch up.

strong ermine
#

Hello, I still think about the best solution for us. The problem is that our platform requires at least the country for the user to specify and we use this information for many business-like processes. If we would use standard account and the user would fill in different country in Stripe there could be discrepancy between our platform and stripe. how would you recommend to solve this potential issue?

odd jolt
#

If we would use standard account and the user would fill in different country in Stripe there could be discrepancy between our platform and stripe.
I'm not sure I understand the ask here, you want to prevent a user fill a wrong counrty while onboarding ?

strong ermine
#

Yes, as we require countryCode (eg. US) entered during account registration on our platform we want to prevent the user to fill in different country on stripe. how to do it?

#

we use the country to manage lots of business logic in sales and distribution and therefore we want the vendor's billing info to be compliant with the data stored in our platform.

odd jolt
#

Yes, as we require countryCode (eg. US) entered during account registration on our platform we want to prevent the user to fill in different country on stripe. how to do it?
I don't see how to prevent this honestly... if the user submit a wrong information, then the connect account will blocked when reviewed

strong ermine
#

ok, so let's take a different perspective - we can (?) check the country entered on stripe during onboarding and if not the same as the one used during the registration we would block the account as well. is it possible?

odd jolt
#

we can (?) check the country entered on stripe during onboarding and if not the same as the one used during the registration we would block the account as well. is it possible?
You can monitor the event account.udpated webhook https://docs.stripe.com/api/events/types#event_types-account.updated and inspect the country. However you'll receive this webhook event only when the account completed the onboarding (not the verification) you can give it a try

#

Otherwise you can use Custom Accounts with API onboarding/verification so that you have full control over the onboarding flow and the user inputs before sending to Stripe

strong ermine
#

yes, I expect that however this would force us to a situation that we are responsible for everything, right?

odd jolt
#

I expect that however this would force us to a situation that we are responsible for everything, right?
this widely depends on the onbaord and the Connect Account and other factors...

#

But again if you want to have 100% control over the onboarding flow, you can use the API and add additional control on the user entries

strong ermine
#

The second part is the UX. two different UI, two different flows, two different platforms. The level of required user's experience can be different on our platform and on Stripe. These are also things that need to be considered.

odd jolt
strong ermine
#

to be honest, we always prefer to communicate with dev-help as we do not have top class experience with stripe business support...

odd jolt
#

Yeah I understand that.

#

but unfortunately this is a dev channel for technical integration question. For legal and simular staff, Stripe Support is better suitted

strong ermine
#

can we at least use Standard connected account to onboard via Stripe UI and manage the tax registations via API or Tax components? So we minimize risks as well as minimize two-platform UX?

odd jolt
#

No Standard Account can be only fully onboarded vai Stripe hosted onboarding

strong ermine
#

including the tax registrations?

odd jolt
#

Yes

strong ermine
#

Ok, let's do some closure: we can use webhooks to monitor connected Stripe account details such as address, tax registrations, etc. once something is not compliant with our platfrom policy we can put the account on hold and inform the owner about that. Once they fix the discrepancies we remove the lock and let them continue. does it make any sense?

waxen marsh
#

hi! I'm taking over this thread.

#

Stripe will itself disable/enable the account if it's not compliant. There's nothing to do on your end.

strong ermine
#

yes, but ti can be compliant on your side but not-compliant on our side!

#

example: during our registration the customer says he's from France (not true) but in Stripe they say they are from United States (true).

#

In such a case the account is not compliant with our policy and we want them to be blocked

waxen marsh
#

got it. then that's something you can do from the Stripe dasboard when looking at a connected account (or directly in the API by disabling capabilities)

image.png
strong ermine
#

we want to do it automatically - so that is why we want to monitor connected user account changes (mainly billing address) which I understood should be done via webhook

waxen marsh
strong ermine
#

we'll do some analysis and hopefully find the best way how to achieve both - security for us and the best possible UX for the users 🙏

#

thank you for your effort. last question: isn't it (somehow) possible to send some "placeholder data" (eg. via url) to connect to pre-fill fields in the ongoing forms when connecting account? something like this: connect?address=street%201&city=My%20city&postal_code=12345&country=USA

waxen marsh
#

how are using using Connect? with the OAuth URL, or by creating new accounts with the API?

strong ermine
#

OAuth so far but we can change it if it makes any sense

#

How to connect STANDARD account via API?

waxen marsh
strong ermine
#

if so we are ready to change it to improve our users' UX

#

thank you for the time being