barbud_docs

[light spade]

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

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

[fair crag]

Hey there, your general structure here makes sense for this flow. WHat exactly do you need help with?

if they add a new card then that breaks the flow since it’s not the “master record” on my platform account so the user can’t use it at another location and would have to re enter the info
this piece seems like a likely candidate, but its the expected flow

You would need to ensure any cards you expect to re-share later are saved at the platform level

Otherwise, as you note, they are only usable on that one connected account

[limber gate]

Basically trying to figure out how to properly accept payments, since when they go to make a payment they have to enter it on the payment sheet for the connected account. The best I can do is tell the user to go to the settings and add the card from there to reuse at other bars. Is there a way to prevent the user from adding a new card so that they’re forced to choose from the existing methods?

Also do I have to keep the database record? I see people sending the connected account id to the payment sheet and I think that should make the payment directly to the connected account right?

https://dev.to/stripe/single-slider-direct-charges-on-multiple-accounts-with-cloning-ic5

[fair crag]

With our Embedded Payment Element, you have some control over enabling saving more cards: https://docs.stripe.com/payments/mobile/accept-payment-embedded?platform=react-native&type=payment&mobile-customer-session=customer-session#react-native-enable-saved-cards

But you might want to consider using your own UI to display the cards you have on file and having the customer choose that way. This would give you the ability to offer a "new card" flow that directs them to your platform-level area.

[fair crag]

You may need to keep track of the mapping between the platform saved PM and the individual connected account customer PMs, since there is no automatic mapping there. Metadata on the connected account PMs can link the platform PM id if you like, or you keep your own version for lookup.

[fair crag]

What do you mean by "sending the connected account id to the payment sheet"? For direct charges, you need to initialize the SDK with the connected account context (Stripe-Account header/option). You might be mixing this up with on_behalf_of which is a different thing.

[limber gate]

I think sending the connected account is in the payment intent/client secret that I use to render the payment sheet

The link above says it requires a certificate, I can’t open it

[fair crag]

Sorry, i fixed the link

[fair crag]

It applies in both contexts, creating the payment intent and setting up the SDK

[limber gate]

Is the SDK part of the front end? I use <StripeProvider> and pass in the connected account id to that in my cart screen and in my settings I don’t pass in anything…on my back end I just have a single lambda layer which is used throughout all the lambda functions, I don’t assign any connected accounts to that one, I think it’s just something I downloaded and zipped and uploaded

[fair crag]

I use <StripeProvider> and pass in the connected account id
Yes, this is what sets up the mobile SDK to use the connected account 👍

on my back end I just have a single lambda layer which is used throughout all the lambda functions, I don’t assign any connected accounts to that one, I think it’s just something I downloaded and zipped and uploaded
You would need to be passing a connected account on the back end too, in order ot conduct payments direct on connected accounts

If you share an example payment intent ID I can verify that for you

[limber gate]

Oh yea I have something like {account : The connected account id } after I pass the price and cloned customer id for that account

Also is the CustomerSheetBeta still the right thing to use? I’m noticing some flickering when I go to close it and not sure if there’s a non beta version

[fair crag]

You probably want to look at upgrading that -- the new embedded payment element with customer session might work better for you

See the note in the customer sheet docs: https://docs.stripe.com/elements/customer-sheet?platform=react-native

Note
The Customer Sheet is intended for use on an app settings page. For checkout and payments, use the Mobile Payment Element, which also has built-in support for saving and displaying payment methods and supports more payment methods than the Customer Sheet.

[limber gate]

Yea I’m gonna take a look at the embedded payment element for the cart screen, but for the platform payment methods which I use to clone into other accounts (in the settings) I can keep using the customer sheet right? Just wondering if there’s another version because it’s the beta and giving that flickering bug when I dismiss it

[fair crag]

Yea i think customer sheet should be fine there. I think there was non-beta release, yes. What version of the SDK are you using?

CustomerSheet exited beta with 0.40.0: https://github.com/stripe/stripe-react-native/blob/master/CHANGELOG.md#0400---2024-11-19

CustomerSheet is now generally available!
If you were using CustomerSheetBeta, change that to CustomerSheet.
If you were using CustomerSheetBeta.CustomerSheet, change that to CustomerSheet.Component

So i expect you must be using a version before 40

[limber gate]

Ok yea im on 38.4, will look into upgrading it thanks!