#matih_best-practices

1 messages Ā· Page 1 of 1 (latest)

bold solsticeBOT
#

šŸ‘‹ 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/1399429000786350090

šŸ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

dry barn
#

The reason I ask this is because in another project we work in, every time we create a customer we also had to set stripe_account

odd ocean
#

We generally don't recommend that with Standard Accounts

dry barn
#

Why not? What are the implications?

odd ocean
#

You could add logic to your integration to save Customers and Payment Methods to the Platform and then clone them to the Connected Accounts and use Direct Charges

dry barn
#

What we would like to do (please let me know if this works):

#
  1. end-user signs up to platform and the platform creates customer in Stripe after emails is verified
  2. TrainerX signs up to platform and completes the Standard Connected Account onboarding process.
  3. the end-user shops around among personal trainers and finds TrainerX.
  4. the end-user clicks to purchase and is sent to stripe.com checkout page where purchase is completed
  5. when purchase is completed, the platform takes e.g. 1ā‚¬ of the payment (application_fee=100)
odd ocean
#

In the last step you mentioned collecting an Application Fee. Application fees are most often used with Direct Charges, where the Customer, Payment Method, and Payment all exist on the Connected Account. Is that the goal here or does the Platform want all the transactions stored on their account?

dry barn
#

I'm not 100% sure what your question is. But let me try to further explain;
When the payment is made, e.g. 50ā‚¬ (unit_amount=5000) we want the platform to receive e.g. 1ā‚¬.

#

Yes, TrainerX should "own" the transaction. They should absolutely be able to see the transaction when they login to their Stripe Dashboard. And they can also see the application_fee (if it's visible - we've got nothing to hide)

odd ocean
#

Okay, I think I get the types of funds flows involved here

dry barn
#

my basic question is; when we create a checkout session (https://docs.stripe.com/api/checkout/sessions/object), is it possible to BOTH set a customer AND the connected account - WITHOUT getting errors that "the customer doesn't belong to the connected account"?

odd ocean
#

Only if that Customer exists on the Connected Account

#

If you are creating the charge on the Connected Account, all the records involved must exist on the Connected Account

dry barn
#

So we need to create a new Customer for every Connected Account that exists?

odd ocean
#

You would need to create a Customer Record on the Connected Account prior to that customer paying that Connected Account, yes.

#

That is why I shared the doc about cloning records

dry barn
#

I see.
Currently all our end-users and Connected Accounts will exist in Sweden. I assume that there wont be any issues

odd ocean
#

Where is the Platform located?

dry barn
#

Platform will be hosted in EU as well.

odd ocean
#

Okay then that should be fine. But if the Connected Accounts start to be located outside the EU that could be a problem

#

do we need to save any information used in any later stage?

What kind of information do you mean?

dry barn
#

All players (users, connected accounts, platform) will be in EU

dry barn
odd ocean
#

Sorry that is extremely vague. Can you be very explicit about exactly what you are doing with the Setup Intent and what account you are creating it on?

dry barn
#

The reason I'm asking all these questions is so that we don't have to develop for 2-3 weeks and then suddenly realise that we're not able to do X because of Y. While your documentation is very detailed, it can sometimes become a bit too verbose.

So, going back to the flow I mentioned earlier - implementing connected accounts, cloning customer data between accounts, will we still be able to send the user to a stripe-hosted checkout page?

dry barn
odd ocean
#

Your questions are not clear enough for me to provide good answers.

Can you provide a step by step list of the actions you are going to take, what accounts they will occur on, and what your expected outcome is?

#

implementing connected accounts, cloning customer data between accounts, will we still be able to send the user to a stripe-hosted checkout page?

This is still far too vague for me to answer in terms of Connect

#

Where are the records stored? On what account is the payment ocurring?

dry barn
#

This is how I understand the process needed:

  • end-user signs up to platform
    • the platform creates customer in Stripe after email is verified
    • the platform creates a SetupIntent stored with the user
  • TrainerX signs up to platform and completes the Standard Connected Account onboarding process.
    • the end-user shops around among personal trainers and finds TrainerX.
    • the end-user clicks to purchase. The platform will clone the Customer to the Account.
    • the end-user is sent to stripe.com checkout page (with payment_intent_data) where purchase is completed
#

Customer records are stored on platform
Payment should be initiated by end-user, to the connected account.

odd ocean
#

the platform creates a SetupIntent stored with the user

This doesn't make sense. Setup Intents are used to save Payment Methods when they are confirmed. Is the Platform saving a Payment Method?

dry barn
#

We** don't** want to save any payment information if possible. We're not PCI compliant, and we're not looking to become compliant

odd ocean
#

In that case you can skip creating the Payment Method entirely and just use the Checkout Session

bold solsticeBOT
dry barn
#

OK. How is the cloning then performed?
Or should we just create a Checkout session with the corresponding stripe_account?

#

But won't we run into the "customer doesn't exist" error then?

odd ocean
#

You still need to create the Customer record on the Connecte Account

#

You just don't need to do anything with the Payment Method

dry barn
#

If we skip the section with Payment Method there's nothing else on that page, it seems

#

step 1: Create a customer on your platform
step 2: Create a SetupIntent on your platform (skip this?)
step 3: Clone the PaymentMethod to the connected accounts (skip this?)

odd ocean
#

Right, sorry. I forgot that new doc doesn't include creating a Customer record on the Connected Account

#

So you will want to create the Customer on the Connected Account prior to creating the checkout session, so you can use the Stripe Account header and process the payment on the Connected Account

dry barn
#

OK. And since we may have 100 connected accounts, each of our customers may have to be "cloned" as many times?

Or is it beneficial to just use the customer_email during checkout and skip the copying?

odd ocean
#

That is entirely up to you and what kind of experience you want to provide

dry barn
#

The checkout page would look the same, no?

odd ocean
#

You can test this yourself pretty easily just by creating a Checkout Session with a complet Customer reocrd and one with just an email

dry barn
#

Our client will have to make a decision if it's worth the extra development time

odd ocean
#

Makes sense

dry barn
#

Thank you for your help!