#mesudev_api

1 messages · Page 1 of 1 (latest)

devout cypressBOT
mental cosmosBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

devout cypressBOT
#

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

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

jolly frigate
#

Hi there 👋 taking a look to see if that's controllable.

low copper
#

that would be quite important to us, otherwise we cannot use the payment sheet as it provides a way to break our entire business logic of the payment methods

jolly frigate
#

What type of app are you building; ios, android, or react native?

low copper
#

We're using the flutter_stripe package for flutter for both ios and android, which according to your support relies on your native mobile SDKs

jolly frigate
#

Ah gotcha, that isn't our package, it's built and provided by a third-party. I'll check whether I can find a way to suppress that in our React Native SDK, but it may still be worth consulting with the support team behind flutter_stripe to see if that directly uses our library and provides access to all of its features.

low copper
#

yeah exactly if there's a way to suppress that with your react native SDK that could be cool, because your support informed me as follows:

"The flutter_stripe library relies on our native stripe-ios and stripe-android SDKs to enable the easiest path to PCI compliance for developers building with Flutter. It reuses the same native code base as our Stripe React Native SDK ".

So knowing where in these packages it's possible, that would be very helpful already.

#

I'm actually thinking of integrating your actual SDKs instead of the flutter_stripe package, (the ones you provide for iOS and Android, instead of flutter_stripe) as this is not the only issue we're having, and it's better to be able to count on possible support in the future. However, if I may ask, I have no knowledge in Swift + Kotlin; do you consider the effort to learn what's necessary to understand your SDKs rather big ?

jolly frigate
#

Well, flutter_stripe isn't our package, so it feels like who you were chatting with may not have been the most familiar with these. It does use stripe-ios and stripe-android, but not directly, it uses them indirectly via stripe-react (as far as I know, again, not our package so I'm not the most familiar with it's inner workings).

A teammate mentioned that if you avoid passing the ephemeral key you created for the Customer, then the saved payment methods should not be displayed or available for editing.

I'm not sure, I also don't know Swift or Kotlin, so I'm not sure how big of a lift it is to learn them well enough to build an app.

low copper
#

oh great let me try that out by omitting the customer ephemeral key then

#

I'll let you know in a sec

#

indeed mate, omitting the ephemeral key = no display of the current payment methods, that worked

#

but the customer ephemeral key is also not needed to store new payment methods?

#

what is its actual purpose?

jolly frigate
#

I believe those payment methods can still be saved/setup for future usage via your code and the API, but I think it suppresses the ability for customers to choose to save those details for reuse in the payment sheet. I'd suggest making sure you can still reuse payment methods created in that fashion as you need in the rest of your flows.

low copper
#

Hmm if the customer ephemeral key is used precisely for that, it's actually perfect for us because then we could precisely omit it without worrying further.

#

Could we maybe indicate at the moment we create the setup intent already that we intend a future usage?

jolly frigate
#

Setup Intents automatically imply future usage, that's their function. You use usage indicate whether you intend to use them for off_session or on_session usage in the future.

low copper
#

ok yeah, there we currently specified off_session. great, I'll check back with the flutter_stripe devs. Do you from Stripe intend to sometime provide a first-party SDK for flutter, like for react native? Just because your support is excellent ^^

mental cosmosBOT
lone sequoia
#

👋 stepping in as toby needs to step away.

#

No plans right now to directly support a Flutter SDK that I'm aware of.

low copper
#

too bad

#

thx!

lone sequoia
#

👍

low copper
#

wait

#

one sec

#

In that approach, no customer ephemeral keys are needed. Could you may explain why?

lone sequoia
#

Yep, that has to do with how security works on mobile vs web.

#

It also comes down to the fact that these flows weren't built exactly the same.

#

Which is unfortunate... but in the past our mobile and web teams diverged slightly in terms of using an ephemeral key for some processes

low copper
#

we're particularly asking because we're using the payment element from stripe js (https://docs.stripe.com/js/element/payment_element), to add a new payment method in web contexts. In the payment method form being loaded, the currently stored payment methods do not show up in the initiated form. Is that behaviour indeed intended? Because we really don't want payment methods to be edited / deleted without interaction with our API, as checks in our system have to be performed first before permitting such actions (e.g. only permit deletion of only payment method if there are no pending payments of booked services for concerned customer)

#

so the behaviour we get using stripe.js payment element is exactly what we want. When integrating stripe for our mobile app, we first faced the issue that the customers' payment methods + the possibility to edit / delete them are by default enabled in the payment sheet integration (react native), except if you do not pass the customer ephemeral key when initiating the setup intent (correct?)

lone sequoia
#

Yep that is the default behavior for Stripe.JS

low copper
#

It's just that I absolutely have to make sure that the customer cannot directly change / delete a payment framework via some UI related to the current payment methods using stripe.js or your mobile SDK

lone sequoia
#

We are working on adding the ability to show saved PMs in Stripe.JS

#

And it should be supported soon, but the default behavior will continue to be that saved PMs won't be shown

low copper
low copper
#

and as for the mobile SDK, can you confirm for both iOS and Android, that, if the customer ephemeral key is omitted when setting up a new setup intent for payment method storage (without immediate payment), the triggered payment sheet does also not show the current payment methods + the possibility to edit / delete them ?

#

the react native SDK*

#

and also your native SDKs, actually

#

?

lone sequoia
#

That is true of all 3 mobile SDKs

low copper
#

great than I can hardly imagine that flutter_stripe is differently done

#

So omitting the customer ephemeral key for the initiation of the setup intent as mentioned above, in your 3 SDKs (iOS, Android, React Native) will exclusively prevent the listing + possible editing of the current payment methods in the payment sheet? Omitting it will not have any bad impact on the storage of the payment method via the payment sheet, or any other negative impact ?

lone sequoia
#

That's correct -- it just limits what we display client-side

low copper
#

excellent, thx

#

As always, crazy good support from Stripe, really, totally appreciated

lone sequoia
#

❤️

low copper
#

In times where so many companies start to switch to AI-chatbots, personal professional support becomes so valuable. please don't switch to bots ^^

lone sequoia
#

I'll pass along the feedback 🙂

low copper
#

so finally just to double-check, omitting the customer ephemeral key when initiating the payment sheet is the best way to go to not show the currently stored payment methods in the payment sheet, + avoid their direct modification + deletion via the payment sheet. Correct? Or is there even a better way, in your current mobile SDKs?

#

Or would you advise against doing so for any reason

lone sequoia
#

There is no better way here, no.

#

And I don't advise against it -- while it is slightly hacky, many folks use this flow (don't pass Eph key to prevent saved PMs shown) so I would never expect us to make a breaking change to this flow.