#starky_api
1 messages · Page 1 of 1 (latest)
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- starky_api, 1 day ago, 24 messages
👋 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/1225778690697334824
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
hi! "saldo" == "balance"?
Hi. yes sorry! I meant balance.
and to be clear, Subscriptions are for Customers (cus_xxx object), people who pay you, not Accounts (acct_xxx) which are merchants or people you pay money to, they are entirely separate concepts.
yes, but our "Merchants" are our customers as well, since they have a platform monthly subscription.
what you can do is create a Customer and an Account, and in your own system/database you say "these are both for the same person", that is common, but there's no real link in the Stripe API between them, it's all in your own business logic
i.e. when you onboard someone, you create a Stripe Account for them and onboard that, and separately you have a form with Elements etc to collect their credit card and save that to a Customer object which you then associate with the same overall "user" in your database.
ah okay! I thought it would be possible to do it within stripe API. One question then, is it possible to control the date the payout to merchants happen? And the amount that is paid to them? And in case they have 0€ to still deduct an fixed ammount to the main account?
well you can set a connected account to manual payouts and then you explicitly call the API when you want to initiate a payout, and for how much https://docs.stripe.com/connect/manual-payouts
And in case they have 0€ to still deduct an fixed ammount to the main account?
hmm I mean that's more complicated. How would that work? The connected account has had no balance for a month let's say(no sales, or whatever). You want your platform to get $100? where does that money come from?
from the account of the connected account. Basically our platform has a licensing fee for the merchants, and we want that if they don't reach the threshold for payout, to then deduct from their account to ours since they are "connected"
like their bank account you mean?
yes
I mean that is maybe possible if you could use Account Debits, which leaves the connected account with a negative Stripe balance, and then we auto-debit their bank account for the negative balance. But since you're a Swedish platform I don't think that's really an option. I also think it's pretty messy and not really how those features are meant to be used.
https://stripe.com/docs/connect/account-debits + https://docs.stripe.com/connect/account-balances#accounting-for-negative-balances
You probably want to talk to a Solutions Architect or something if you're in contact with Sales about this platform you're building. But there's no easy answer here, it's a complicated set up we poorly support.
The alternative is just that you charge the associated Customer object's saved payment method( that could even be a sepa_debit PaymentMethod that is their same underlying bank account they use for payouts) for whatever fee it is that you want, but then you need all the bookkeeping to know/connect that payment to being related to the connected account. No easy solution here, it's all really complicated.