#jordan-paymentsheet-ios

1 messages · Page 1 of 1 (latest)

obsidian bane
ebon field
#
  1. When we create a SetupIntent and instantiate the PaymentSheet (or a PaymentSheet.FlowController in our case) for a customer who already has a payment method on file, the FlowController's PaymentOptionDisplayData has a value (presumably this is coming from the customer's existing payment method). But the SetupIntent doesn't have a payment method attached yet, so confirming it immediately results in an error (which is expected). Why is this the case?
  2. The .intent property of a PaymentSheet.FlowController is private. So when the PaymentSheet is dismissed (either by the user selecting a stored payment method or adding a new one, or by cancelling the Sheet), the only thing exposed via the SDK api at that point-in-time is PaymentOptionDisplayData (flowController.paymentOption). This presents two issues:
    2a) As a part of our internal order creation process, we need to attach a payment_method id to an order to be charged offline later when we actually start the fulfillment process. This seems to require a separate request to fetch the actual payment_method object created with the SetupIntent that has just been confirmed. Is this the expected flow, or is there another way to get the payment_method id immediately without making a separate request?
    2b) If the customer has a stored payment_method, presents the PaymentSheet, and then dismisses (cancels) it without adding a new card or selecting an existing card, the FlowController's PaymentOptionDisplayData still has a value for .label and .image, which represents their existing stored payment_method. Upon dismissal, this makes it hard to know whether or not the user cancelled the Sheet, or just selected their existing payment method again. Do you have any guidance here for how we might detect these different states upon dismissal?
obsidian bane
#

(reading)

ebon field
#

Apologies for the long questions!

obsidian bane
#

all good

astral kite
#

👋 HI @ebon field I'm hopping in to try and help

#

Can you show me some of the code you're using to present payment sheet? From my understanding, FlowController should also have paymentOption (https://stripe.dev/stripe-ios/docs/Classes/PaymentSheet/FlowController.html#/s:6Stripe12PaymentSheetC14FlowControllerC13paymentOptionAE0bG11DisplayDataVSgvp) populated after the Payment Sheet has been dismissed (https://stripe.dev/stripe-ios/docs/Classes/PaymentSheet/FlowController.html#/s:6Stripe12PaymentSheetC14FlowControllerC07presentB7Options4from10completionySo06UIViewE0C_yycSgtF)

ebon field
#

FlowController's paymentOption is a very high-level, cosmetic object- all it represents is .label (last4) and .image for a card, but those are supposed to be used purely for reflection in our UI on the checkout page. So there isn't a payment_method ID that we can grab from that

astral kite
#

Ahhhh you're right, I missed that

ebon field
#

I can definitely show you our code, but it would be more efficient to have a call (I think it would be much faster to get the gist of what we are trying to accomplish). Are you okay with a Zoom call?

#

Also, thanks for taking the time to respond to our questions!

astral kite
#

We don't do zoom calls here unfortunately - but I'm happy to look at any code you send over here

ebon field
#

Okay no problem- I'm on another call at the moment, but I can send you code examples in a bit if needed

#

In terms of presenting the payment sheet, we are just following the recommended way of doing so according to the Stripe iOS SDK docs- nothing special there

#

In terms of priority of my questions:

#
  1. Is mainly curiosity- it seems odd to me that the PaymentOptionDisplayData for a PaymentSheet.FlowController should have a value if a payment_method hasn't yet been attached to the SetupIntent used to create it
    2a) We can work around this by sending another request to fetch the payment_method id for this newly confirmed SetupIntent. I'm just curious if there is a better way to get this data directly from the SDK without sending an additional request.
    2b) Is somewhat of a blocker for the functionality of the PaymentSheet in our checkout flow, so I'm mostly interested if you have any guidance about this
astral kite
#

1) Is mainly curiosity- it seems odd to me that the PaymentOptionDisplayData for a PaymentSheet.FlowController should have a value if a payment_method hasn't yet been attached to the SetupIntent used to create it
Yeah, this one struct me as odd as well and I was a bit confused over how you were getting into that state. From re-reading everything now I see what you're saying - that even BEFORE the payment sheet has been presented + dismissed PaymentOptionDisplayData has been populated when you weren't expecting it to, correct?

#

2a) We can work around this by sending another request to fetch the payment_method id for this newly confirmed SetupIntent. I'm just curious if there is a better way to get this data directly from the SDK without sending an additional request.
Let me check in on this one a bit more

ebon field
#
  1. That's correct- the values for PaymentOptionDisplayData are populated with values as soon as the FlowController is instantiated (for a user with an existing stored payment_method)
#

But obviously a payment_method hasn't yet been attached to the SetupIntent used to instantiate this FlowController, so we can't immediately confirm it without the SDK throwing an error. We aren't trying to immediately confirm the intent, but I'm just mentioning it

astral kite
#

2b) Is somewhat of a blocker for the functionality of the PaymentSheet in our checkout flow, so I'm mostly interested if you have any guidance about this
Can you give me a bit more clarity here - is your goal just to be able to differentiate between the user cancelling it w/o selecting any other user action (selecting a different Payment Method, creating a new one, etc) vs cancelling it after additional UI interaction?

#

and one quick question - which version of the SDK are you using?

ebon field
#

A pretty recent one - 21.10.0. I would have said the "most recent" version, but I just ran a pod outdated and it shows that 21.11.1 is available now

#

If you think there's a difference, I can easily update to that version

astral kite
#

No, I don't think the update will make a difference - for context, I believe what you're running into is behavior introduced a while ago (https://github.com/stripe/stripe-ios/pull/1445) where a Payment Option is "pre-selected" which would explain why PaymentOptionDisplayData is being populated so early

ebon field
#

Gotcha- that makes sense, but that is just for the PaymentSheet functionality, correct? Not really to be used at that point by users?

#

In the interest of preserving your time, I'm happy to move on from 1) as it doesn't really affect work on our end

#

As for your reply on 2b) above, our goal is to determine whether or not we should confirm this SetupIntent. If the user has cancelled the Sheet without selecting a payment_method, confirming the SetupIntent will result in an error. But related to 1) (and 2a) to some extent), the PaymentOptionDisplayData for the FlowController will have a value for users with an existing stored payment_method. But as I mentioned above, there isn't a guarantee that the payment_method has been attached to this SetupIntent yet

astral kite
#

Yeah, it's just PaymentSheet functionality - you wouldn't want to confirm it at that point

ebon field
#

Additionally, even if the user did select a payment_method via the PaymentSheet UI, just looking at the PaymentOptionDisplayData's label isn't a unique identifier to determine whether or not the card "changed", or is different than another card with the same last4 (this latter part is an edge-case though)

astral kite
ebon field
#

No, from my testing the PaymentSheetResult will be completed when the user cancels the PaymentSheet via the "X" button at top-left. This was somewhat of a surprise to me, but on further reading of the docs it seems that the canceled status is used for cases in which the user quit the verification process of the SetupIntent (like 3D Secure, etc)

astral kite
#

That's still a surprise to me - let me dig into that a bit more

ebon field
#

And also, the PaymentSheetResult status is only returned when we attempt to confirm a FlowController, which happens after dismissal. There is no accessible status returned from the callback block to presentPaymentOptions that gets triggered immediately after PaymentSheet dismissal (that I can see, at least)

#

For a customer with no stored payment_method on file, we can get around this by checking for the existence of PaymentOptionDisplayData (flowController.paymentOption). If it doesn't exist, we just don't confirm the SetupIntent. But for customers with stored payment_methods there doesn't seem to be a way to detect that we shouldn't confirm the SetupIntent at that point of dismissal of the Sheet.

astral kite
#

are you doing something different?

ebon field
#

Oh we aren't waiting for a button or anything

#

We have a button that presents the PaymentSheet.FlowController (via flowController.presentPaymentOptions). That function has a callback block that gets triggered upon dismissal. So within that callback, we are calling flowController.confirm to confirm the FC / SetupIntent. And that call will result in an error in the case where the user hasn't actually attached a payment_method to the SetupIntent via the PaymentSheet (tapping the "X" on the PaymentSheet to dismiss it)

#

So for users with no previously stored payment_method on file (we are just looking at the existence of PaymentOptionDisplayData (flowController.paymentOption) upon FlowController dismissal, unless advised otherwise), we can skip the confirm call in that dismissal block. But for users with a previously stored payment_method, we can't rely on that paymentOption property because it is no guarantee that the user has actually selected a stored card and implicitly attached it to this SetupIntent

astral kite
#

From what I understand of our ios sdk (and to be fair, i'm not the best with ios) this may just be something we don't support right now. For the most part, users who I've seen using the custom flow with the Payment Sheet are implementing their own button which triggers confirmation, which completely bypasses the edge cases you're running into. Really, the change on our end that would have this work for you is disabling the pre-selected option functionality that was added in https://github.com/stripe/stripe-ios/pull/1445, and from a quick glance at the code I don't see any way to disable it entirely (but I didn't get a chance to take a deep look). Your only other alternative would be to pivot and add an additional button to know when to confirm

ebon field
#

Separating the confirm call into a separate button doesn't really solve the issue here. The SetupIntent used to instantiate the PaymentSheet.FlowController could still not have an actual payment_method attached to that Intent if the user cancelled the Sheet via the "X" button

#

IMO there are at least two changes I would propose to the Stripe SDK on iOS in this case:
a) expose the .intent object property on PaymentSheet.FlowController to public rather than private accessibility, or..
b) return some type of status from the presentPaymentOptions return block that will allow devs to detect that the sheet was cancelled via the 'X' button at top-left of the Sheet.

In our case, we would prefer a), because it would also solve for my original 2a) question above without requiring a separate trip to the server to get the newly attached payment_method id

#

Also, in terms of the pre-selected functionality in https://github.com/stripe/stripe-ios/pull/1445, I totally get why this was added (it enables the green checkmark icon on the user's preferred payment_method when they open the PaymentSheet). But it would be great if a) was added as functionality because devs could know at point of creation of a PaymentSheet.FlowController which payment_method was already selected by default (and not just the cosmetic PaymentOptionDisplayData). It doesn't really affect what we would do in terms of our UI (as mentioned in my replies about my original question 1) ), but I could imagine a scenario where this would be useful for certain checkout use-cases

astral kite
#

@ebon field I do need to head out, but someone should be by really soon to help some more - this will almost certainly have to be escalated up to the ios team

ebon field
#

Okay sounds good- I'm about to jump off for dinner as well but I'll be back online later this evening

#

I very much appreciate you taking the time to look into this with me!

burnt peak
#

Hello, Taking over and catching up. Spare me a few mins!

ebon field
#

Sure, and thanks!

burnt peak
#

(a long thread and still trying to grasp the context. Let me also reproduce on my sample project)

ebon field
#

For the 2b) problem, I can think of a workaround. But it would basically involve making a separate request to Stripe upon PaymentIntent.FlowController dismissal to fetch the SetupIntent object used to create the FlowController (using the SetupIntent's client secret via retrieveSetupIntent on apiClient). From there, we can determine if this SetupIntent has a paymentMethodID attached, and if it doesn't we know not to confirm this SetupIntent / FC. But this seems like a pretty roundabout way to achieve our goal at this point in the code- we just need to know whether or not the user has attached a payment_method to this SetupIntent. The PaymentSheet clearly has knowledge of this, so is there a reason that the Intent property isn't exposed to devs?

#

It doesn't seem like exposing this property to public is "less secure" bc we would be using the same client secret to make this additional request. Is the concern that devs would try modify the Intent object's properties if it were public? If so, there are ways to prevent that from an SDK standpoint. But I'm not entirely clear on Stripe's SDK api design priorities

#

And as I mentioned above, in our use-case we would still need to grab the payment_method ID from a newly-confirmed SetupIntent to attach it to our internal representation of an OrderSubmission object to be charged later offline. Our backend would then use this to create a PaymentIntent later when we actually start manufacturing a customer's order. So in the short-term, it seems like we would need to make an additional request to get this new STPSetupIntent object to grab the paymentMethodID anyways. It's just that it would be amazing if we could get that from the PaymentSheet.FlowController instead without the need to make an additional request bc the data obviously exists client-side within the Stripe SDK already at that point- it's just not exposed to devs

burnt peak
#

Yes your ask ring true to me and I remember to have the very same concern myself when I played with the SDK. Please spare me times to exploring around to see if we have options or another recommendation elsewhere

#

The whole point does make sense that if PaymentMethod Id is available it would be more convenience

ebon field
#

I really appreciate you taking the time to investigate- thanks!

#

And yes, it would be perfect if payment_method were available via the PaymentSheet

burnt peak
#

Correct me if I am wrong, if you have the PaymentMethod Id, what's the plan of using it? Will you send it to your backend, and your backend decide to confirm it or not?

#

Oh

So within that callback, we are calling flowController.confirm to confirm the FC / SetupIntent
This is a client logic?

ebon field
#

In our use-case and on our mobile and web apps, there would be client-side confirmation of a SetupIntent, but no creation of a PaymentIntent for checkout with normal cards (but this is different than Apple Pay, which I won't bring up here)

#

Our backend would then take a payment_method ID which gets attached to our internal OrderSubmission object and create a PaymentIntent later (offline) when we actually start manufacturing a customer's order

#

But to your reply above: yes, everything I've mentioned here in this thread pertains to client-side logic and I'm talking about the iOS Stripe SDK

ebon field
burnt peak
#

By client-side confirmation of a SetupIntent, which method do you refer to? I am getting my app running and I am using paymentConfirmationSheet on SwiftUI and want to have a similar context as much as possible

ebon field
#

We are using Swift, but the API shouldn't make a difference vs. SwiftUI

burnt peak
#

Oh okie it also confirm the SetupIntent, so similar

ebon field
#

By "confirm" I just mean that we are calling the confirm method on a PaymentSheet.FlowController, which implicitly confirms the underlying SetupIntent

burnt peak
#

Yes it does the same thing, sorry for the confusion

ebon field
#

No worries

burnt peak
#

Choosing a card and haven't click on the Pay/Checkout button just yet

ebon field
#

It's similar, yes - our customers add their chosen cards separate from tapping "Buy"/"Checkout". But what I'm saying is that relying on the existence of paymentSheetFlowController.paymentOption is not sufficient to determine whether or not the user clicked 'X' or whether they chose a valid payment_method via the PaymentSheet UI

#

So in the example you provided, if this user had a stored payment_method already and clicked 'X' to cancel the PaymentSheet, there would be two issues:
i) There will be no way to tell, based on paymentSheetFlowController.paymentOption, that the user just cancelled the PaymentSheet and didn't select a payment_method, and
ii) Based on the state of paymentSheetFlowController.paymentOption here isn't a direct or strong way for us (developers) to detect that the user switched a card. We don't have visibility into the underlying payment_option data. We can look at last4 (paymentOption.label) for comparison, but some of us might also need the payment_option's ID to use for fulfilling orders. There isn't any way to detect if a payment_method has been set on the underlying SetupIntent, so at the point of dismissal of the PaymentSheet I'm not entirely sure if this SetupIntent should be confirmed or not

burnt peak
#

Yes I totally understand the point of paymentOption, it doesn't really provide any specific information related to what was chosen, and understand that's what you want

#

digging around the implementation of the SDK since it's opensource anyway

#

Hoping to get some UserDefault and see if there is a way to access it. Currently I am here: defaultPaymentMethodID

ebon field
#

paymentOption seems to be entirely cosmetic, and that can be useful but it's not what we want here

burnt peak
#

This doesn't seem public

#

If you try to do the same thing, inspect if there is com.stripe.lib:STPStripeCustomerToLastSelectedPaymentMethodKey UserDefault with key of your current customer Id, can you get it?

ebon field
#

We have already written an internal endpoint to return a given customer's preferred payment_method. We are going to use this to return the data we want on every Checkout screen load. If the user has a most-recent payment_method, that's great - we just attach the payment_method's ID to their OrderSubmission when they check out (no involvement of the PaymentSheet or SetupIntents). But if they want to change their payment method there are issues, as mentioned above

burnt peak
#

Yeah, but I am trying to pull out a workaround on client to take the current selected PaymentMethodId, by looking at the same UserDefault key that the SDK saved. It sounds very hacky, but I just want to know if that works

#

(trying myself)

ebon field
#

I've already read basically every Stripe doc on SetupIntents, PaymentIntents, payment_methods, on both iOS SDK and direct API docs, so I feel very familiar with how the Intents API works at this point

burnt peak
#

(by inspecting the SDK source, it seems like the SDK just saved that info to UserDefault, then we should be able to pull it)

ebon field
#

It does seem to me to be a bit hacky to do it that way, but I'm open to options

burnt peak
#

When customer click on any payment method inside the PaymentSheet screen, here is the actual place things are going on

#

For example this cell

Screen_Shot_2022-01-12_at_15.57.01.png
ebon field
#

This may work, but in my opinion it seems like in the short-term the "cleaner" solution would be to just do the workaround I am proposing here:

ebon field
#

So I can do this, but I would like to escalate this use-case/issue to your iOS SDK team. I think there is room for improvement here on Stripe's side in terms of what is accessible to devs. I don't really consider our integration/migration/use-case to be particularly wild or complex, and I would be somewhat surprised if other devs haven't run into this same or similar issue

burnt peak
#

I am afraid your suggestion won't work, because each time customer switching their options, there is nothing actually happen on Stripe's data. It's just the UserDefault on app changed

#

if you invoke your backend to make a request to Stripe, I am afraid the paymentMethod is still null

#

You can confirm it by try to switch PaymentMethod on your app, then separately use Stripe CLI to retrieve the SetupIntent

ebon field
#

Alright, so then I would consider this an issue with Stripe's iOS SDK

burnt peak
ebon field
#

And if my workaround won't work, then we are essentially blocked in terms of development

burnt peak
#

After a few switching on iOS

ebon field
#

Thanks for providing the data from your testing

burnt peak
#

Since the only action occurred is the SDK saving chosen option to UserDefault, there is no other thing we can do other than inspecting UserDefault, I think

ebon field
#

As I mentioned, referencing UserDefaults seems very hacky

burnt peak
#

Yes agree. But by design, the customer's action of choosing on PaymentSheetUI, actually doesn't trigger anything other than saving those information on UserDefault

ebon field
#

Especially if as a dev I would be referencing UserDefaults for data that is controlled by a 3rd-party SDK (Stripe)

burnt peak
#

So it's by design that you won't have any information at that time

#

Especially if as a dev I would be referencing UserDefaults for data that is controlled by a 3rd-party SDK (Stripe)
100% agree

ebon field
#

So could you please escalate this to your iOS SDK team? It seems like this is something that should be fixed/enabled

burnt peak
#

I think the correct approach would be still letting the confirm on SetupIntent happens, but handling its error gracefully

ebon field
#

As a short-term fix, that is also an option. But to me it's clearly a sign that something is broken in terms of functionality

burnt peak
#

After confirmation happens, then you can invoke your backend to pull the latest PaymentMethod Id used, like you mentioned in your workaround. It just need to be done on confirmation callback

ebon field
#

And also, the confirm callback returns a completed status in the case that the user has cancelled the PaymentSheet via the 'X' button

#

So this isn't even an "error" really in terms of the PaymentSheetResult

burnt peak
#

Yeah, agree that event confirmation result is very generic. It's basically an enum with 3 outcomes

#

I will bring this this iOS SDK team for sure, thank you for sharing all the context and I believe it will add up to the point SDK team would improve. For now, your 2a) suggestion seems to be the only option

2a) As a part of our internal order creation process, we need to attach a payment_method id to an order to be charged offline later when we actually start the fulfillment process. This seems to require a separate request to fetch the actual payment_method object created with the SetupIntent that has just been confirmed. Is this the expected flow, or is there another way to get the payment_method id immediately without making a separate request?

ebon field
# burnt peak Mine

Just so I'm clear from your testing, was this prior to confirm / immediately after dismissal of the PaymentSheet?

burnt peak
#

prior to confirm, after dismissal

#

without confirm, nothing really happen on Stripe's side

ebon field
#

Okay so that might be what I need actually

burnt peak
#

To summarize, here is what we have known so far

  1. After customer choose any options inside PaymentSheet, only UserDefault has changed and nothing actually happen on Stripe's data. And it's impractical to look up those value
  2. After customer tap "Checkout", the actual confirmation call happens, then Stripe's data will have the selected PaymentMethod. However it's not exposed to the callback of confirmation call on client, therefore you can only invoke your backend to pull that information back from Stripe, then to your iOS
ebon field
#

User taps to present the PaymentSheet, clicks 'X' to cancel, we make a separate request to fetch the SetupIntent object and if there is a null for payment_method, we don't need to confirm the SetupIntent. Any issues with that?

burnt peak
#

No issue, it sounds correct to me

#

I mean, even if user choose any payment method or click X, it's the same result that you fetch the SetupIntent and receive null for payment_method

ebon field
#

Right, but as I mentioned above in the thread, we can cheat here somewhat by looking at the existence of flowController.paymentOption. If that is nil, we don't need to send this separate request (and we can skip the confirm step) for users who don't have a stored payment_method on file

#

But yeah, for existing users with stored payment_methods we are going to need to essentially send 2 extra requests that we shouldn't need to (in my opinion)

burnt peak
#

I agree about "cheat" for user tapped on X and skip the step. But can you outline again the flow for existing users? The part with 2 extra requests

#

I am thinking of only 1 extra request on confirmation callback, because the extra request on selection callback won't returns anything at all, and you can skip it too

ebon field
#

So to clarify what I meant (for users with already existing payment_methods):

#
  • We can't "cheat" upon PaymentSheet dismissal, so we need to send a request to get the SetupIntent and see if a payment_method has been attached. If so, we are good to confirm that SetupIntent. If not, we can break.
  • But upon successful confirmation of this SetupIntent, we still need to grab the selected payment_method ID to attach to our OrderSubmission, so this would require another request.
#

We can also cheat on the latter by keeping track of the value of the payment_method ID requested on the former (thus not firing the second request). But frankly this all seems pretty hacky to me and doesn't seem like the intended ease-of-use priority that Stripe wants to design their SDKs for.

#

I love Stripe, and I'm a big fan of your products. Payments are hard and Stripe has abstracted a lot of the heavy-lifting for that and enabled many small companies (like us) to not have to deal with a lot of complexity. I just feel like the iOS SDK could be marginally improved here for our specific use case (which I would imagine many other devs have encountered before).

burnt peak
#

Thanks for the write up, and for your opinion. I would like to make sure we are on the same page.

upon PaymentSheet dismissal, so we need to send a request to get the SetupIntent and see if a payment_method has been attached.
My understanding is that this request will always returns null, because at this time nothing has happened on Stripe's data yet

ebon field
#

I wasn't entirely sure what you meant based on your testing, but if that's the case my workaround won't work and we are still in a bit of a pickle

#

I'm going to test on my side

burnt peak
#

Sorry the original file was too big. Hope you still able to see what happen here

ebon field
#

My testing also shows that the payment_method will be null here

burnt peak
#

So yes, you would want to let the confirmation happens anyway

ebon field
#

Okay, so in the short-term would that mean that we also need to do the UserDefaults hack?

burnt peak
#

The other question is, do you really need to know what was chosen here? How about just going forward to confirmation?

ebon field
#

We can confirm, but the SDK will throw an error

#

In the 'X' button dismissed case

burnt peak
#

That isn't reproducible to me. Could you tell me more about the error case? That you have an existing customer, with some payment methods already?

#

when you open the PaymentSheet and before tap on X, how is it displayed?

ebon field
#

Huh, this is weird

#

For my user who has a stored card, if I tap on our button to present the PaymentSheet (which creates a new SetupIntent via our internal endpoint via Stripe), and use that to instantiate a PaymentSheet, if I tap on 'X' to dismiss and then confirm that FC / SetupIntent, it gets completed

#

But I'm not seeing the printout of the error I was seeing before in the console, which was something like "You can't confirm a SetupIntent if payment_method is null"

#

But I was definitely seeing that before, even if the PaymentSheetResult was still completed upon confirmation

burnt peak
#

It could be a different error/issue than we thought. By design I believe the confirmation call should work with any outcome of user selection on PaymentSheet's UI

ebon field
#

Okay- I can do more testing tomorrow, as it's getting late on my end

burnt peak
#

Hope this helps things move forward a bit on your end

#

I will write a report to SDK team about exposing paymentMethodId on the callback of selection and confirmation

ebon field
#

Regardless, I don't think these transactions I've described should require additional trips to the server to either 1) fetch the payment_method ID for a confirmed SetupIntent, or 2) try to detect that the user has cancelled the PaymentSheet via the 'X' button. This data already exists within the SDK in some form, so it would be great if this was opened up to devs via the SDK

ebon field
burnt peak
#

It would be more convincing if I can provide a usage that actually needs it. At this stage I only can convince them on the callback of confirmation call, which will save you the roundtrips to fetch it after confirmation

ebon field
#

So the dismissal of the PaymentSheet block should also have some status of whether or not the user cancelled it bc then we wouldn't need to look at the flowController.paymentOption as a (imperfect) proxy for whether or not a payment_method has been attached to this SetupIntent or not

#

That happens pre-confirmation

#

And if that functionality were added it could prevent needless confirmation requests for certain cases

ebon field
burnt peak
#

For pre-confirmation aka dismissal of the PaymentSheet, I think clicking on X is equivalent to clicking on the already marked green Card, no?

ebon field
#

In production currently yes, that seems to be the case for the iOS Stripe SDK for users who have a single stored payment method on file

#

But when I've tried to confirm the FC / SetupIntent for users without an existing stored payment_method (so they just present the PaymentSheet and dismiss it via 'X'), this has resulted in an error within the Stripe SDK. It is an assert that would crash the app

#

So I just need a way to detect this 'X' dismissal case and then I know that we shouldn't try to confirm this SetupIntent. Right now there is not a way to detect this

#

Hey I'm about to hop off for the night, but I will check back and can also do some further testing on my end in the morning

#

Feel free to reply in the meantime- just expect a delayed response for a while

burnt peak
#

Yes, thanks and good luck