#manoj5506
1 messages ยท Page 1 of 1 (latest)
-
You can create "platform" accounts that are still connected to you as long as you create them as Standard Accounts. I'm not sure what you mean by registering in this case.
-
Multiple accounts is for having multiple accounts for the same business as a way to separate out different parts. I don't think that applies here.
@brazen hollow
#1 ah ok, so what is different needs to be done for making use of "Connect".
I came across this example where we provide connected account details when creating payment intent. Apart from that what changes are required in the stripe integration?
curl https://api.stripe.com/v1/payment_intents
-u sk_test_4eC39HqLyjWDarjtT1zdp7dc:
-d amount=1099
-d currency=usd
-d payment_method_types[]=card
-d transfer_data[destination]=test-acc-2
#2. Thanks for confirmation on this.. ๐
I'm sorry but I'm still unclear on exactly how your current integration uses Connect. Could you describe it in succinct bullet points?
Sorry, my question is not clear. Currently we are not making use of Connect.
- We are making use of Stripe.net SDK for stripe integration.
- Our users of the application are connected to stripe with our custom UI and integration through backend.
- Today lets say servicegrouprovider
SG1is able to take payment from customerC1. Now we want connect to allow supplierS1,S2as well to take payment from customerC1
_ I was looking at this docs page about how to make use of connect and was trying to understand changes required.
https://stripe.com/docs/connect/explore-connect-guide
Our users of the application are connected to stripe with our custom UI and integration through backend.
What does this mean? Are you creating connect accounts for them?
Basically user gets redirected to connect.stripe.com
User login into existing stripe account and authorize access to account by our application.
Okay so these are standard connect accounts
Okay so reading your last bullet point. What do you mean there?
Would the supplier be under the connect account or separate entirely?
supplier will be a separate entity
Okay in that case you would need to clone the customers from the original account onto the supplier connect accounts
I would recommend reviewing this doc thoroughly to ensure you are familiar both with the code/APIs but also the business case and what this would mean for your workflows
https://stripe.com/docs/connect/cloning-customers-across-accounts
Got it. Let me take this as a starting point and go through it thoroughly.
One last question - can standard accounts created in stripe be converted to a platform account?
What do you mean here? It doesn't look like you are creating these accounts yourself since your users already have Stripe accounts they link to your platform.
yes these accounts are created by customers. For e.g today we have a supplier group "SG1" who takes payment from customers "C1, C2, C3". Now tomorrow I want to allow "C1, C2, C3" to make the payment to 2 other suppliers as well "S1, S2" who have their own stripe account. So just copying the customer data would be sufficient in this case?
If it is sufficient, it solves my business problem.
You're correct, I may not need to worry about platform account.
Hi! I'm taking over from my colleague. Please, give me a moment to catch up.
sure, np!
If you perform Destination charges you don't need to copy the customer data, you will just transfer the funds to another Connected account.
sorry could you please help me understand meaning of "Destination charges"?
When the customer charge happens on the Platform (with transfer_data[destination]), and the funds transfered to the connected account. As oposed to Direct charges - when customer is charged by the connected account directly.
Is this applicable only in case of "Stripe Connect"?
Yes
ok. Let me give some more info just to be clear.
Let's say we collect credit card info of patient "p1" to make payment for business "SG1". And user normally makes payment to this business.
There is a supplier "S1", for whom the patient "p1" should also be able to make the payment.
So in this case when I create payment intent, I will create it with "transfer_data[destination]" and provide stripe account details of "S1". (From stripe perspective "SG1" and "S1" are separate entities).
Will this use case work fine with "destination-charges"?
Yes, in this case all customer data and PaymentIntents will be saved on the Platform account, and you will just choose which account to transfer the funds to.
But currently "SG1" is not a platform account. It is a standard connect account.
Please correct me if I am wrong.
To make "Destination charges" working, "SG1" should be changed as a platform account on the stipe end.
Ok, I understand you have 3 layers of Stripe accounts?
- Your app - Platform account
- Supplier group - Connected account
- Supplier - ?
Are suppliers individual entrepreneurs?
Yes right, suppliers are individual entrepreneurs.
Does stripe consider my web application as a platform account?
It is just connecting supplier groups to stripe. Patients do not see my application's name in their credit card bills.
Stripe account hierarchy doesn't need to exactly map your org/client hierarchy.
Depends if you want customers to be able to reuse Payment Methods across all your supplier groups/suppliers.
ok. So we need to change it like this. This way payment methods can be used to pay for Supplier Group, as well as supplier. Am I correct?
Supplier group - Connected account [change to] -> Platform account
Supplier - [set this as] Connected account.
I am not sure yet. Do you want customers to be able to reuse Payment Methods across all your supplier groups/suppliers?
Or just within the same supplier group?
Just within the suppliergroup.
Customer "C1" should be able to pay for one supplier group and multiple suppliers in that supplier group.
Customers data is not shared between the supplier groups.
Because you could skip the Supplier group in the Stripe Connect hierarchy and just have your app as a Platform, and suppliers as connected accounts. Then you could associate suppliers to each other in your database/using matadata.
But I think in your case you might actually want to have 3 layers. Will each supplier accept payments on their own website? Or customers pay through your app?
Sorry for going in circles, there's many possible configurations and I want to make sure we choose the most suitable one.
Customer pay through our web application only.
If we set up app as a platform, will the billing details seen to patient with our application name?
We want it to be transparent element, Suppliers Groups and Suppliers would need their name to be seen in the billing.
When using destination charges you can set the settlement mechant: https://stripe.com/docs/connect/destination-charges#settlement-merchant
I would say then the webapp needs to be the platform.
ok thanks for your input. Let me start working on this direction ๐
I just want to know pros and cons of other approach as well to be better equiped with quries in the team.
If an alternative approach other than platform account is required, then can we use approach suggested by Snufkin_stripe?
If I understand correctly, we will need to clone customers data from for e.g. SG1 to S1 stripe account.
https://stripe.com/docs/connect/cloning-customers-across-accounts
I would definitely use destination charges between SG1 and S1. The question is whether you need 2 or 3 layers, and whether your Platform charges the customers, or SG1.
We do not charge end user customers. We charge SG1.
I mean, from Stripe perspective.
Does the Platform charge the Customers, takes a fee and transfers the rest to the SG/S, under the hood.
The customer might see something different, but this is how money movement might look on the technical level.
Also, given the customers pay in your app, it makes sense for the Platform to charge the Customers. Again, talking about the technical level, not who pays who.
ok got your point. Frankly speaking, I am not sure how the fess is charged to customer by our application. But thanks for help. I got the info requierd and work on this futher ๐
Happy to help.