#BrianHHough
1 messages ยท Page 1 of 1 (latest)
Hey there ๐ sorry, your previous thread was closed when we didn't hear back from you, but I've started a new one for us to use.
Before we go to far, I want to touch on this point:
Standard would accomplish this right? It's just a way to send money from one stripe CustomerID to another stripe CustomerID.
This is not correct, Connect is not meant for sending money from one Customer to another Customer, sending funds to a Customer is not supported.
Connect is most commonly used for marketplaces/platforms, or more generally when multiple providers are involved with providing the good/service being purchased.
So using your Lyft example. In this case, the driver would have a Connected Account, and the people they're giving rides to would be represented by Customers.
You, as the Platform Account (the Stripe account that is at the root of a Connect integration that orchestrates everything), will take payments from Customers and disperse the funds from those payments to your Connected Accounts.
Oh interesting...thank you for clarifying. Glad I reached out to ask ๐
Trying to wrap my head around this:
-- So every driver to RECEIVE funds would need a Connected account
-- And every rider to SEND funds to a driver would need to just be a normal stripe customer
Is that correct?
Yup, exactly.
Amazinggg!
And when a driver requests funds from a customer, there is an invoice created, but how does it know the paymentIntent of where the money goes?
I'm familar with how the invoicing process works but for products where the money goes back to the stripe owner....not a connected account I guess.
Can you help me understand how the paymentIntent would get set up via connect so that it goes from RIDER (customerID) to DRIVER (connected account)?
....like for example, I know you can inject the customerID into the invoice session.create API to autopopulate that user for the invoice.
Is there some sort of method for autopopulating the stripe connected account for the recipient of the funds?
Connect is a bit more complicated than that.
The first thing to decide on is what type of charge structure you want to use.
https://stripe.com/docs/connect/charges
Separate Charges and Transfers is the most complicated, and typically only need if there are multiple third-parties per transaction (such as someone loaning out a vehicle and a separate driver who both need to get paid) or if you need to make adjustments to your platform's fee depending on specifics about the payment.
Destination Charges or Direct Charges are easier integration paths, and which you want depends on the type of experience that you want to offer your customers.
If you want your customers to feel like they're interacting directly with your platform, then Destination Charges are a better fit. If you'd rather have an experience where it is more obvious that your customers are interacting with third-parties, then Direct Charges are a better fit.
Thank you so much @serene sail! When you say "a bit more obvious" - do you mean the stripe invoice pops up? Or that you could do it all from within react.js code via api?
We wouldn't need to worry about loaning or anything...this would just be for driver does a ride...that ride is X amount...create a session to allow rider2 to pay driver1
Oh and our account takes a % of that transaction
and for right now, don't want to worry about a connected account "holding a balance" - want the money to just be added for payout, but not make the user withdraw
Apologies for my lack of clarity. It's more about the customer experience than it is about the technical steps to implement at this time.
When using Destination Charges, your platform is the merchant of record. So Invoices you generate, will have your platform's name, logo, and branding applied to it. If you instead used Destination Charges then the Invoice branding would be inherited from the Connected Account, giving the customer more of an impression that they're interacting with your driver rather than your platform.
Oooooh i gotcha, i can see how this would good for a shopify store for example....invoices BY the store themselves than Shopify.
I think we'll go with Destination Charges cuz it's all under the company platform!
Sounds good! Based on what I'm hearing that is what I would have recommended as well.
This guide walks through the gist of how to use Destination Charges, but the exact steps will fluctuate based on the integration path that you're using.
https://stripe.com/docs/connect/destination-charges
Destination Charges were designed to work with either Express accounts or Custom connected accounts. Integrations that leverage Custom accounts require more work to build and maintain, so I would recommend using Express accounts unless there is a business scenario that is critical to you which they can't handle:
https://stripe.com/docs/connect/express-accounts
The key thing with Destination Charges though, is setting the transfer_data.destination parameter to the ID of the Connected Account that you would like to receive the funds.
Accounts are created on automatic payout schedules by default, which sounds like it aligns with the behavior that you're looking for.
Collecting fees on transactions is controlled by the application_fee_amount or application_fee_percent value that you specify when creating the objects in Stripe to handle a payment:
https://stripe.com/docs/connect/destination-charges#application-fee
Ahhh this is what I was wondering about....didn't realize the transfer_data.destination would be so handy here in using the API. Very cool!!
I think Express means each user needs to pay $2/month right? I thought Express had charges involved, but can't find this page.
๐
stepping in as toby needs to step away
Yes Express does involve $2/month for active accounts. You can see Connect fee structure here: https://stripe.com/connect/pricing
So for Destination Charges, is there a reason why you'd have to use Express rather than Standard? Just trying to keep costs low at the moment.
Just to test this out, I'm afraid $2/mon for anyone to set up a connected account could become really expensive if a bunch of people were setting up connected accounts.
To be clear, it is only $2/month for active Connected Accounts
I believe that is only for those accounts that you have initiated a payout to that month
I'm not an expert in fees though and you can double check that with our Support team: https://support.stripe.com/contact/login
That said, yes you should not use destination with Standard
One of the main reasons is that you are going to run into issues with refunds and reporting
With Standard Accounts the Connected Account user has full access to a Stripe Dashboard
So they could technically attempt to refund a payment for instance. However, that refund of the payment will just move the funds back to your platform
Not to the actually end-customer
You have to control everything here from your platform with destination charges so you don't want to give access to a full Dashboard with a Standard Account. You will run into a lot of headaches in the future.
Destination charges are designed for Express or Custom Connect
Thank you so much for all this helpful info!! You probably saved me an insane amount of headache down the road ๐ ๐
np!
also, another question on this...when a payment is successful, are these events streamable via API? I Know there is the sessions.completed API, but do these types of connect payment events come up differently from created sessions?
The recommendation is to use Webhooks here. And the same Webhooks will fire for destination charges as the Session is occurring on your platform
oh yes sorry i meant webhook -- i set this up for the sessions.completed too
You can also use a Connect Webhook endpoint to specifically listen for Events that occur on a Connected Account: https://stripe.com/docs/connect/webhooks
Sweet! Thanks so much for this!