#manoj5506

1 messages ยท Page 1 of 1 (latest)

candid sorrelBOT
brazen hollow
#
  1. 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.

  2. 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.

pliant zenith
#

@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.. ๐Ÿ‘

brazen hollow
#

I'm sorry but I'm still unclear on exactly how your current integration uses Connect. Could you describe it in succinct bullet points?

pliant zenith
#

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 SG1 is able to take payment from customer C1. Now we want connect to allow supplier S1, S2 as well to take payment from customer C1
    _ 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

Read more about how Connect works and integration choices you can make.

brazen hollow
#

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?

pliant zenith
#

Basically user gets redirected to connect.stripe.com
User login into existing stripe account and authorize access to account by our application.

brazen hollow
#

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?

pliant zenith
#

supplier will be a separate entity

brazen hollow
#

Okay in that case you would need to clone the customers from the original account onto the supplier connect accounts

pliant zenith
#

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?

brazen hollow
#

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.

pliant zenith
#

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.

simple iron
#

Hi! I'm taking over from my colleague. Please, give me a moment to catch up.

pliant zenith
#

sure, np!

simple iron
#

If you perform Destination charges you don't need to copy the customer data, you will just transfer the funds to another Connected account.

pliant zenith
#

sorry could you please help me understand meaning of "Destination charges"?

simple iron
#

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.

pliant zenith
#

Is this applicable only in case of "Stripe Connect"?

simple iron
#

Yes

pliant zenith
#

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"?

simple iron
#

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.

pliant zenith
#

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.

simple iron
#

Ok, I understand you have 3 layers of Stripe accounts?

  1. Your app - Platform account
  2. Supplier group - Connected account
  3. Supplier - ?
#

Are suppliers individual entrepreneurs?

pliant zenith
#

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.

simple iron
#

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.

pliant zenith
#

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.

simple iron
#

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?

pliant zenith
#

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.

simple iron
#

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.

pliant zenith
#

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.

simple iron
simple iron
pliant zenith
#

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

With Connect, you can clone your customers' payment information across multiple connected accounts for reuse.

simple iron
#

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.

pliant zenith
#

We do not charge end user customers. We charge SG1.

simple iron
#

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.

candid sorrelBOT
pliant zenith
#

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 ๐Ÿ™

simple iron
#

Happy to help.