#nick-dm_best-practices

1 messages · Page 1 of 1 (latest)

raw anchorBOT
#

👋 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/1333361404052373555

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

quaint chasm
#

hi there!

#

if you don't want to show the Stripe UI to your users, it's possible using Custom accounts. however note that we rarely recommend uing this, because it requires a lot of work on your end to build all the UIs.

real shard
#

Thanks Soma, I had another couple of questions if that's ok? I've not been able to receive the answers via the normal support channels, nor the Sales reps/account manager I've been speaking to

quaint chasm
#

if it's technical questions, sure!

real shard
#

For context: Our company is a Catering PaaS service, which offers a platform for caterers to expose their menu's to the public, manage/take orders and so on. For each of our clients, they provide us with their Stripe details and we embed the normal UI features and the payments go to them.
We have created a new product - catering quotes - and we want to streamline the onboarding process for potential clients. This would mean we'd want them to sign-up without having to create their own Stripe account.

#

Question: Currently (with our existing product) we have embedded the normal Stripe payment components in our UI when customers of our clients want to pay for their orders, and use the relevant API keys/Secrets to connect to the relevant client's Stripe account. If we used the Caterdesk Stripe account for accepting payments, would we do this in the same way then utilise the Stripe Connect product to distribute those funds accordingly, or is there a separate set of UI components we would have to use? I've not seen anything in the docs that would suggest we'd have to do this but with the additional UI components that can be exposed I thought it best to check.

quaint chasm
#

If we used the Caterdesk Stripe account
what is Caterdesk? one of your connected account?

real shard
#

Sorry, yes - Caterdesk is the name of our company (and my colleague recently created a Stripe account under that name, but hasn't finished activating it yet)

quaint chasm
#

and we embed the normal UI features
and what is this? Payment Element? Checkout Session? Something else?

real shard
#

These are the payment elements, used in our Next.js React app

#

(Including the PaymentElement, yes)

quaint chasm
#

so you are currently using the Payment Element with your own Stripe account, and you want to know how to use the same Payment Element with a connected account?

real shard
#

So each of our clients currently has their own Stripe account - they've given us the Publishable/Secret keys and the signing secret for the webhook. When they are receiving a payment via our PaaS UI, we connect their Stripe account to take the payment (with checks to listen to the relevant events done in our back-end)

quaint chasm
#

they've given us the Publishable/Secret keys
got it. so you want to replace this setup with a connect setup?

real shard
#

To simplify the process for our new quoting product, we'd want to use our Caterdesk Stripe account and distribute the funds accordingly using the Stripe Connect product, so our new clients don't need to provide all the keys/secrets as this has been troublesome for them.

quaint chasm
#

that's a great idea!

real shard
quaint chasm
real shard
#

That's something I'm not sure of yet, and wasn't sure if tech/support/sales was best to chat to about them. If we used Stripe Connect in the way I am postulating, would there be a recommendation? Ideally, we'd want to avoid showing our clients own customers (i.e. members of the public ordering food from our clients via our platform) any fees. Our current business model charges a percentage of the order totals for each client (e.g. they take an order of £1000, we charge 3% per order so we'd take £30 and they get £970)

#

Again, recognise this may be treading out of the tech-side of things, but got a call with a Sales rep tomorrow morning to chat about charges and whatnot

quaint chasm
#

have you read the page I shared that explain the difference in details?

real shard
#

Yes, I've read that one previously and again when you sent the link, but the way in which we decide to go wouldn't be up to me directly (I'm just one of the engineers)

quaint chasm
#

got it.

#

but this choice will impact how your implementation works

#

so first you need to decide this, then follow the apropriate docs to do the implementation

#

but you can continue to use the Payment Element yes.

real shard
#

Ok, my instinct is that we'd use the Direct Charges option because our platform is available internationally. We currently have clients in Europe, Oceania and Asia, so the caveat in the Destination Charges option makes it less attractive.

quaint chasm
#

assuming you use Direct Charges:

  • you create the PaymentIntent on your own account, using the Stripe-Account header: https://stripe.com/docs/connect/authentication
  • you mount the Payment Element with the public key of your own account, and set the Stripe-Account header
    and that's it, it should work.
real shard
#

That's great, thanks Soma. Last question from me for now:

  • If my colleague finishes the set-up for our Caterdesk account, can we use the Stripe-Connect in a test-mode (like you can with the normal platform) so we can test it out in our staging environment first?
quaint chasm
#

absolutely.

#

you can use your account test API key to create connected account. and they will be in test mode.

real shard
#

Good stuff

#

I think that's everything for now, thanks for all your help Soma

#

Are these channels closed by the way or do they stay open indefinitely?

#

(So I know if I need to copy our conversation for my notes or not!)

quaint chasm
#

happy to help 🙂