#mikemod_
quick dove
empty tide
Hello there
untold prairie
Hello
empty tide
Can you share your questions here please
untold prairie
I brought two questions that I am currently trying to understand, if you can help me.
First
I am a little confused about the architecture I should implement within Stripe. Our business modal has connected accounts for different purposes—one would be an affiliate account that receives payouts, and the other would be a connected account that also receives payouts derived from this affiliate account. What do you recommend? Should I create another main account to handle these two flows? My concern is that I might do this and not be able to establish the necessary links between accounts, users, payments, etc
I think this is more clear
The second
empty tide
Where is Stripe/Connect in that picture?
untold prairie
Without wanting to take too much advantage of the developers' goodwill here, would it be a good practice to automatically include everyone who creates an account on our site as a customer within Stripe? Our business model is a marketplace, and by default, everyone who registers is a potential buyer, but only a portion will actually make a purchase. If anyone has any considerations on this, they are very much welcome
untold prairie
Where is Stripe/Connect in that picture?
The affiliates are in my view, a potential connect stripe account because they have payouts, indeed the restaurants could be an potential conenct stripe account too because the also have payouts
empty tide
Well you can't nest connected accounts like referenced on your image so that's a non-starter
From your image it sounds like:
- Fomefiel (your business?) would be a Stripe Connect platform where restaurants are connected accounts
- Each affiliate is also separate Stripe Connect platform where the same restaurants are connected accounts there too (that is permitted – an account can be connected to multiple platforms)
untold prairie
The diagram is agnostic, merely illustrating the flow of the business model logic; it doesn't take nested considerations . It was just a thought present in programming, indeed, but I envisioned it as a linear process from the beginning.
fomefiel yes my business
let my understand i bit, wait
Your first sentence is correct, the lyft is the best example, we are an intermediary
about your second sentence
Our interest with affiliates is just a way to sell our product to restaurants and allow them to earn commissions on sales, that's it.
So, I linked that to pay commissions, they would also need to have connected accounts...
empty tide
What does the process look like for an affiliate selling to restaurants?
I think there's really only one way to do this. Here's how I'd probably model it:
- A single Connect platform (Fomefiel)
- Multiple connected accounts than can represent either an affiliate or a restaurant connected to that single platform
- This will allow you to transfer balances between your platform and those accounts, and facilitate payouts to their external accounts
- You can track affiliate sales different (via metadata perhaps), and for those payments the platform would send funds to the relevant affiliate connected account from the platform
untold prairie
What does the process look like for an affiliate selling to restaurants?
There are sellers of training courses for restaurant management and professionalization or courses for paid traffic campaigns. The majority are influencers on social media platforms like Instagram who sell these services to restaurant owners. The strategy of discount coupons or links offered to their students is not very clear to me, but it seems to be a way to strategically save on marketing expenses for the company prospection.
untold prairie
I think there's really only one way to do this. Here's how I'd probably model it...
Ok, just to clarify.
I was unsure if the correct approach was to mix the dashboard of a main account (Fomefiel) with connected Stripe accounts with different scopes/purposes. In this case, yes, despite the disorganization it may cause due to being different entities in my business model, Stripe doesn't have a way to distinguish them in this manner, did I understand correctly?
Secondly, going beyond your question about the proposed implementation.
Is it possible to do this: A connected affiliate account generates a restaurant customer, simultaneously, I create this same restaurant as a connected account. Is there any impediment to this approach? Does this understanding seem correct?
and I'm not in a hurry, you can respond to people at your own pace, my friend.
empty tide
Stripe doesn't have a way to distinguish them in this manner, did I understand correctly?
Distinguish what sorry? I'd imagine you'd buidl your own dashboard(s) using your APIs for your integration. You shouldn't rely solely on the Stripe Dashboard to operate your business
A connected affiliate account generates a restaurant customer, simultaneously, I create this same restaurant as a connected account. Is there any impediment to this approach? Does this understanding seem correct?
Yep, that's pretty common. You can then map that Customer object (cus_xxx) to an Account (acct_xxx) via metadata
untold prairie
Cool, you helped me.
Regarding my other question, do you have any insights?
I'll forward it.
Would it be a good practice to automatically include everyone who creates an account on our site as a customer within Stripe? Our business model is a marketplace, and by default, everyone who registers is a potential buyer, but only a portion will actually make a purchase. If anyone has any considerations on this, they are very much welcome
Is there any maximum limit on usage, user registration, etc?
empty tide
Would it be a good practice to automatically include everyone who creates an acc...
If a connected account is required to purchase services from your platform (e.g. services fess) then yes it'd be good to create a related Customer object on the platform to facilutate that
empty tide
Is there any maximum limit on usage, user registration, etc?
Nope!
untold prairie
If a connected account is required to purchase services from your platform (e.g....
No, i thinking about the customer of restaurants
we are like a doordash, uber eats
so we are handling with payment credentials
to different restaurants
so on each user cadastration , u can think a ordinary people creating an account in uber eats
we will store on stripe
sounds good?
empty tide
Oh, right. What kind of payments would you be doing? I assume destination?
untold prairie
I'm not sure if I understood your question! I'm sorry, my English is good, but it fails sometimes. Can you rephrase it?
empty tide
I would assume based on what you're described is that restaurants will be Express accounts and you'll be doing destination charges
In a Express/destination charge scenario the customers (i.e. people who buy food) would be customers on your platform
There they can add/manage payment methods to be used across all restaurants
untold prairie
Perfectly, grateful for your patience. The restaurant is a guest within our platform; we share all user information, and the user eventually goes to the restaurant's profile and makes the purchase.
untold prairie
There they can add/manage payment methods to be used across all restaurants
Exatctly my man
empty tide
Perfectly, grateful for your patience. The restaurant is a guest within our plat...
I get that, but it's important to understand the account/charge types you'll be using as it can impact liability, flow of funds, etc. See: https://stripe.com/docs/connect/accounts
Most of what you describe is an Express account (I think), so read through that and confirm
untold prairie
Yes, from what I've seen, I imagine that the Express account is ideal for the restaurant's side. What left me in doubt is the need to store each user registration in Stripe.
Another approach would be to create it only if the user gets close to making a purchase or actually makes the first purchase... but anyway, from what I understand, there's no right or wrong.
empty tide
Yes, from what I've seen, I imagine that the Express account is ideal for the re...
So I'd imagine when a customer comes to Fomefiel, they'd be represented by a Customer object that you create on the platform which will allow them to save payment methods. You can then use the cus_xxx when creating the payments for their orders to create an 'order history' etc
empty tide
Another approach would be to create it only if the user gets close to making a p...
Yeah that's just an implementation detail of your app
empty tide
np
untold prairie
Can I ask more questions in this chat in the future if I have any doubts?