#shane
viral peak
arctic yoke
Ask away!
finite swift
Cool thanks!
For context, I'm developing an ad network, web based to start.
So how I imagine it would work is that:
-
Users are members of teams, and can top up their team balances. (and/or get paid out if they are the ones selling ad space on their site via the service - the team owner is the one who would be receiving a payout). If they are buying ads, can allocate X amount of their balance to an ad campaign - or perhaps a specific ad in any campaign.
-
Another feature is buying static ad space, i.e. publishers could list ad space for a fixed price over a fixed time frame.
-
An example would be, an advertiser bought ad space for $50 for either 10,000 impressions, or 50 ad clicks etc (dynamic ad space)
-
After the impressions are complete, or clicks have reached the quoted amount - a payout would then be processed, minus a service fee which could be flat fee, a percentage, or maybe both... something along those lines.
Is that something that is feasible with stripe connect or would this require something much more bespoke?
Actually, let me reformulate this
arctic yoke
There's isn't a great deal of Stripe specific context here, but overall it sounds like a use case for Connect yep. Your 'teams' would be accounts connected to your platform, where you can facilitate the flow of funds between them and you
finite swift
And in terms of products etc. would it be a case of creating products for each ad/ad campaign perhaps and having usage based billing on them, or would it be a case of just handling everything on my side and simply pay out to users based on my app logic? Thoughts?
Maybe creating an ad would be a type of subscription with usage based billing, but isn't reoccurring
arctic yoke
Well, used based billing is recurring by nature. If you want ad-hoc usage based payments you'd need to build that system yourself
finite swift
Yeah that's what I was thinking based on the docs, so basically teams are user accounts, and everything is managed application side in relation to who/when payouts are made seems to be the way to go - would this be an issue theoretically if there were thousands of users/teams (some day)
arctic yoke
No, a platform can have infinite (I think) connected accounts
finite swift
Nice, and I guess finally, would it be suitable to essentially have all users be topping up into one large bucket/the service account like that? Would that raise any issues or anything?
arctic yoke
Depends what you mean by 'topping up'? And who are the users? If each 'user' is sending funds to an account/platform, then they themselves need to be onboarded and verified by Stripe
finite swift
Sorry, teams would be accounts as I understand it - they can top up their team balance to spend on ads etc. Because I'll need to manage the usage and allocating of the balance, from a stripe perspective - the balances will all be in I guess my stripe account, and then e.g. after usage meets requirements for payouts etc, payments will be made from my account alone - like there will be no products, subscriptions created or anything
So all stripe sees is my account, receiving and paying out connected accounts to the service with no additional details, about why who received X amount etc.
Maybe that's a non issue, I guess that's why I'm asking, just want to make sure I have everything done correctly, and above board
arctic yoke
Any entity/individual paying funds into your platform needs to be represented as a Stripe verified account. How you model that is dictated by your business
finite swift
Thanks a million! That gives me enough to work with for now, much appreciated 🙂