#kenneth_best-practices
golden ferryBOT
👋 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/1379752391674429511
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
toxic falcon
👋 happy to help
I think the best place to start is by reading this doc https://docs.stripe.com/connect/charges and choosing which type of charges suits your use-case the most
keen crow
I am dealing with Direct Charges only
keen crow
I am able to make charges to the Connect Account ID. That is not my question. My question is if there's any difference between the 3 ways of "applying" the Account ID to the payment intent? Do they all do the same? Or are there one of these options that is better than the other?
toxic falcon
the different ways are for different type of charges
this is why I linked to you the way to do it for Direct Charges
since this is the only thing you're interested in
keen crow
So, just to make sure.. There is a difference between using the params.SetStripeAccount("{{CONNECTED_ACCOUNT_ID}}") (which is the one used in the example you gave me), and then adding the account ID to the Stripe Context in the BackendConfig of the client?
Because, currently, I am doing the BackendConfig version, and it seems to work - but I am just not sure if it is any different than using the SetStripeAccount(...) on every single request param in my code.
toxic falcon
oh
the difference is that one is global (BackendConfig) and one is on a per request (SetStripeAccount)
sorry I misunderstood your question at the start
keen crow
Okay. So.. it does the same - just in a different way. I just wanted to make sure that I wasn't doing it wrong by adding it one time.
For each transaction in my system, a client is initiated in the system, and that 1 client might make multiple API requests before the context is Done. So if I can just define the Account ID that 1 time when the client is initiated, I won't have to remember to set the account ID anywhere else when making requests.
But I think we understand each other now, and agree that those 2 options has the same outcome, so I can use one or the other.
And that "On Behalf Of" isn't used for direct charges.
toxic falcon
correct
keen crow
Awesome. Thank you for helping me out!
toxic falcon
the only thing I would caution you against is the way you handle multiple connected accounts
unless you're working in a stateless server, you don't want to store the Account ID globally otherwise you wouldn't be able to use multiple Accounts
unless you do like a Map of Account ID -> Stripe Instance
and I'm not even sure that's a good way to handle it
keen crow
When I receive a request, a new Stripe Client is created. When the request is done, that client is terminated. So it's on a "per request" basis, and therefore not shared between different requests.
toxic falcon
just out of curiosity how you would be injecting the Stripe Client? or are you just passing it down?
keen crow
The company I work for is an online payment gateway provider, currently facilitating millions of requests daily for many different kinds of Payment Methods. So we are implementing Stripe Connect as a custom solution, to be able to provide a few payment methods that we cannot provide ourselves because of certain requirements (like Klarna), or that might not be popular enough here to make a dedicated integration of. So, when a merchant creates a payment (via their webshop), we already provide the payment window etc. And when that payment window is opened, and a payment method is selected, a new payment (intent) is created for that specific payment.
And that basically means that we will do what is necessary in the backend, for that specific payment and that specific payment method. So when the customer wants to use Klarna (in this case) via Stripe Connect, we create a new Stripe Client, with the Account ID of the merchant (who has been onboarded to Stripe Connect), and does all the requests in the backend, so we can forward the customer to the Klarna website. This will terminate the current session in our end, and terminate the Stripe Client.
We do this for each individual payment session/transaction, so there will never be a crossover between the Stripe Client used. I simply spin up a new Stripe Client, and implement an interface that does all the stuff.
toxic falcon
I was just curious from an architectural level that's it 😊
keen crow
No worries! 🙂 But yes.. The Stripe Client is initiated and "wrapped" in a struct that is implementing an interface. So initiated when we receive a request, and terminated again when request is done. So kinda "passed down"..
golden ferryBOT