#alecpope

1 messages · Page 1 of 1 (latest)

glass remnantBOT
chilly osprey
#

No, the customer that you created in platform isn't accessible in connected accounts

ember dove
#

Hmm, so every time a new customer buys something from a connect account, I need to create a new customer inside the connect account? --> A user has multiple customers associated to it in different connect accounts?

chilly osprey
#

It's up to you on how to manage the customers, and yes you need to create a customer in the same connected account as the product.

ember dove
#

Okay, I thought there is a "global" customer that is being shared between the connected accounts. Thanks for the clarification!

chilly osprey
#

I'm afraid that's not possible

ember dove
chilly osprey
#

That article is talking about cloning sources from platform to connected accounts

#

And if you read the example code, it still create new customer objects on connected accounts.

waxen dome
#

Do you really need the customer to exist within the connect account?

ember dove
#

Yeah, right. It also uses the deprecated Sources API :/. So what is the best way to manage the customers across multiple connected accounts? Do I need to sync them manually (for example when the default payment method changes?)

To give a little context: Connected accounts can upload products on the platform that everyone can see. Customers can buy these products (from multiple connected accounts). Best case would be that this can be done in one transaction

waxen dome
#

It sounds like how my marketplace works. I don't create customers under connect accounts - there is no need. They're under the main platform account only. I'm using separate charges and transfers though.

ember dove
#

Cool! How do you currently manage your customers? For example, I want to create a subscription in the connected account, but it doesn't find the customer, because it is in the platform account :/

waxen dome
#

I don't deal with subscriptions so it might be very different.

Customers are all under the platform account. When they 'checkout' on the site, they can purchase products from multiple connected accounts at once. A single charge is made by the platform account, before calculating how much to transfer to each connected account. Owner of the connected account is emailed or pushed order/customer information. They can also view it on our custom portal which is accessing most order/customer data from our database (not stripe).

ember dove
#

Okay, so in your case you collect the money and split it between the connected accounts? The connected accounts don't have customers/payments/...

And order information is managed on your site?

waxen dome
#

Yep. Though we attach a good amount of metadata related to the order on the payment in stripe.

chilly osprey
#

Thanks @waxen dome for jumping in and help! What you described is the destination charge flow, which is recommended for Express and Custom Connect accounts. @ember dove if your connected accounts are of Standard type, you should use Direct charge instead.

waxen dome
#

The connected account still sees 'payments' in their dashboard - but it is essentially a 'transfer' from the platform account.

ember dove
waxen dome
#

You can attach metadata to the transfer also - such as customer name, order number etc, so the connected account owner can see that detail, if you're not giving them access to some kind of portal on your website.

ember dove
waxen dome
#

@chilly osprey It's not the "destination charge" flow i'm using, it's the "separate charges and transfers" flow.

ember dove
#

So I think the best way (without having multiple customers in each connected account) is to create the subscriptions in the platform account (with metadata that it is "owned" by a specific account). When we receive a payment for this subscription, we transfer the money to the connected account. Therefore there is only one customer for each connected account. What do you think @here?

waxen dome
#

These are the two reasons I use that flow....

Using separate charges and transfers requires a more complex Connect integration. You can use this charge type if your business has any of these traits:

  1. A one-to-many relationship. For example, a payment made to a delivery service needs to be split between the store (the source of the items being delivered) and the delivery person.

.....

  1. Transfer amounts greater than the associated payments. For example, a platform provides a discount to its customer but pays its user the full amount.
ember dove
#

But isn't a destination charge doing this for you automatically? Reading the short explanation: "[...] you can create charges on your platform account, take fees, and then transfer remaining funds to your connected accounts."

waxen dome
waxen dome
ember dove
#

Oh, right. Okay, then with destination charges I would need to create 3 payment intents, when the customers buys products from 3 different connected accounts?

waxen dome
#

Yes that is my understanding.

This is one reason why I use separate charges and transfers.

The other reason is that I need the customer's payment to be less than the amount transferred to the connected account in many cases:
a) using a discount code issued by the platform
c) using a credit note/gift voucher issued by the platform
This ensures the connected account still receives their normal amount while the platform has funded the discount or credit note.

ember dove
#

So the platform basically pays for discount, while the connected account still receives his requested price?

#

So, I guess I can use destination charges for subscriptions and need to use charges and transfers for products