Multiple Stripe Accounts
proggeramlug opened this issue · comments
I have a strange request, but it's a thing:
So I have a service that will charge different stripe accounts. How should the config be configured for that? We need some kind of a way to either replace the given stripe config - or to use multiple configs at the same time.
As of right now it does not look like either the Vapor-Services nor the structure of this package allow for that.
Any suggestions or ideas?
@proggeramlug
Do you know if any of Stripes official libraries support this?
@Andrewangeta The PHP library has a global variable that you can adjust whenever you want. Like you just set another set of variables in this case:
https://github.com/stripe/stripe-php
Python makes you add the configuration to every request:
https://github.com/stripe/stripe-python
And in NodeJS you can simply reinitialize the stripe object with a new config:
https://github.com/stripe/stripe-node
I know that the Service-Structure is very convenient here because it saves variables globally in this case - I'm just wondering if there is a way that we could adjust that so that the config can also be modified on the fly.
@proggeramlug Yea we'll have to investigate it a little more to figure out an approach. I see the value though.
Sorry to resurrect a dormant thread, but while this behavior exists in some other Stripe client libraries, using this behavior to create Charge objects (or otherwise interact with the Stripe API) in the context of different Stripe accounts isn't really something that Stripe wants integrations to be doing. The canonical way to have one codebase interact with multiple Stripe accounts is to make use of Connect and have each Stripe account that the codebase needs to interact with be a Connected Account under the Connect Platform whose API keys the codebase is using.
I'd be curious to hear more about why you are doing this @proggeramlug and I might be able to help you come up with an integration path that is more closely aligned to a preferred integration path.
PS: I work at Stripe on the team that maintains the official API client libraries - feel free to email me at zwick@stripe.com if you don't want to discuss your integration in this public forum.
@zachwick I'm fully aware of Stripes capabilities and how this is supposed to work on a big scale. We are using stripe for some orders in our app (www.fuelish.de ) and have an order processing service that is doing that for us.
We have a small number of merchants (currently just one) that needs to process orders through the app. All of the stripe accounts are maintained by the merchant but we get full credentials.
The easiest way to integrate this now is to simply plug in the credentials for the respective merchant and chare them into their account. We are not interested in taking an application fee or have any other fee's other than the stripe fee associated with the purchase.
Since it is currently only one merchant we are okay with it as it is, but if and when there will be more we need to be able to change the credentials on the fly.
Making sense @zachwick ?
Hmmmmm so it sounds like merchants create their own accounts but give you access? What would be the point of them creating their own accounts at that point?
Unless their accounts aren’t dependent of your business.
For them to receive the money and us not being involved in the money part at all? :)
Either Stripe Connected Accounts or the money going through our stripe account will add significant overhead in terms of liability, legal responsibility, and management - compared to just use their accounts.
You can still do the same with standard connect accounts right? All the responsibility will be with them and the fees etc will be on the business not you. Standard or express might be worth looking into. https://stripe.com/docs/connect/accounts
@Andrewangeta does this current stripe package here provide functionality for connected accounts? the other thing is that it stripe connected accounts come with fee's for the platform: https://stripe.com/connect/pricing
how would that be worth it for less than 5 accounts total? I'd much rather just have their credentials used for this and don't have to pay the fees nor deal with the money at all.
@proggeramlug That makes sense, but is not an integration path that Stripe encourages. Using Connect, while it does require a small amount of additional engineering work, ensures that your integration and use of Stripe's products (and your client's use of Stripe's products) is in compliance with the Stripe TOS/SSA and all that. At some point, this copy-and-paste of your client's API keys will get caught by Stripe's monitoring around these kinds of integrations and you'll be reached out to with a strong suggestion to move to using Connect (you'd need more than a handful of clients using your software this way before we reach out).
Just because you are using Connect, you aren't required to take an application fee or otherwise insert your platform into the flow of funds. Using Standard Connect gives you legal protection in the guise of Stripe's TOS/SSA and ensures that the financial liability for chargesbacks and such remain with your client and not with you (you can read more here https://stripe.com/docs/connect/accounts#choosing-approach). Additionally, as is called out on the Connect Pricing page that you linked to, there are no additional per Connected Account fees for using Standard Connected accounts.
@zachwick so standard accounts are free? okay cool, we might do that at some point. for right now we only have one merchant and there is no point to over-engineer this quite yet. we'll cross that bridge when we get there.
@proggeramlug Sounds perfect! Feel free to reach out to me over email (zwick@stripe.com) if you have questions about using Connect or want feedback on a proposed design.
@zachwick thank you! :)
@Andrewangeta is connected accounts in this library currently available? It looks like it is.
Yep the standard accounts with connect are supported
Perfect, I'll close this issue for now as it looks like that is a valid work-around.