#josha_ios-3ds

1 messages · Page 1 of 1 (latest)

tawdry forgeBOT
#

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

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

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.

dusky cloud
#

So far, it seems like we want to perform the 'Add a Payment Method' flow using an off-session configuration. Does this ensure 3DS will never show during this UX flow?

summer orbit
#

josha_ios-3ds

dusky cloud
#

As far as showing it during checkout, it seems like if the iOS client manually confirms the PaymentIntent at the time of purchase, it will always be presented there, if necessary.

#

Is this an accurate understanding? And is there any other necessary configuration that might be required here?

summer orbit
#

I don't really get the logic of wanting to skip 3DS upfront since it can lower the change that 3DS will be needed in the future

dusky cloud
#

Our product designers have decided they want to reduce the friction of adding a payment method. I am just the messenger. 🙂

#

However, if there's a point to be made here that we're missing, I'd be happy to know and relay that.

summer orbit
#

Sure but it's important to push back when the ask doesn't make sense

#

There is no way to force skip 3DS really.

dusky cloud
#

Could you expand on that?

#

(Also, to be sure: We're not attempting to totally skip 3DS... just move it to a spot that's deemed more convenient for our app's UX flows.)

summer orbit
#

To collect card details you use a SetupIntent, confirming that SetupIntent will automatically require 3DS when needed based on our data or waht the bank asks. So most of our pre-built UIs won't let you configure that kind of thing and I'm mostly saying you're trying to optimize the wrong way and it's best to just drop it.
I get the ask, but I don't see a way it's possible with our normal iOS integration in a durable/safe way.

dusky cloud
#

Ok. When you say 'confirming that SetupIntent', is this ocurring inside PaymentSheet implementation in the SDK when the user taps the 'Set up' button?

summer orbit
#

yes

dusky cloud
#

Gotcha.

#

Follow-on question: We're migrating our iOS implementation from STPPaymentContext and STPPaymentOptionsViewController (the 'old' way of adding a card) to PaymentSheet.

I have been told by a colleague - but not personally verified - that the 'old' STPPaymentOptionsViewController approach never triggered 3DS. And so, during the checkout flow, we have the iOS client call STPPaymentHandler.shared().confirmPayment(intent... during the checkout flow, which was viewed by my colleagues as a necessary step to trigger 3DS at that step of the UX flow.

Is our understanding of this even accurate? (It seems to be true in practice.)

And, if so, is it not possible to divide it up like this with PaymentSheet?

summer orbit
#

I don't fully follow your train of thoughts I'm sorry 😅

#

If you are using confirmPayment() that confirms a PaymentIntent and will do 3DS if necessary.
But if you are calling confirmSetup() that will confirm a SetupIntent which works the same

dusky cloud
#

So just to... confirm... you're saying confirmSetup() is occurring in the iOS SDK's PaymentSheet implementation when the user taps the 'Set up' button on the 'Add a payment method' card form, correct?

summer orbit
#

As far as I know yes. You give it a SetupIntent's client_secret for it to work in the first place right?

dusky cloud
#

Yes

summer orbit
#

So yes that's what it does. There isn't a flow with PaymentSheet that lets you just create say a PaymentMethod pm_12345 and then do something with it server-side such as attach it to a Customer yourself.

dusky cloud
#

Got it.

summer orbit
#

no, none of this will work with iOS

#

Like it's doable but using older integration paths that you are migrating off of right now

dusky cloud
#

Got it. Ok, that's the information I was looking for. Thanks for your confirmation of everything here.

summer orbit
#

Sure thing!

dusky cloud
#

@summer orbit Are you familiar with this aspect of the iOS SDK?

Screenshot_2024-10-10_at_6.54.26_PM.png
#

This appears to be a value that iOS integrations can pass to the closure that the SDK uses to ask us for the SetupIntent client secret and... perhaps complete the 'Add a card' UX flow without actually confirming the intent?

#

sorry, disregard. that @_spi designation prevents us from calling that variable.

summer orbit
#

I've never heard of this but it looks more like a hack we would have inserted

#

Honestly my read is that you don't want PaymentSheet at all for this flow. You want your own UI, collect card details yourself and then attach that card to a Customer server-side with nothing else happening. But that requires using the older/deprecated APIs that you are trying to migrate off of

#

But we go back to "trying to do this doesn't really make sense" and I'd recommend pushing back on your designer really

tawdry forgeBOT
dusky cloud
#

We've been using the 'Basic Integration' and Stripe UI component for 'Add a card' (e.g. STPPaymentContext) for years and our described UX flow was possible (e.g. 3DS confirmed later, during checkout, via PaymentIntent confirmation).

However, we recently got notified by our Stripe liason that Stripe wants us to migrate to the newer SDK (and associated UI components) which seem to operate differently.

#

Now, I'm trying to determine if there's just different defaults with backwards compatibility somewhere in here, or this is a deliberate change that is unavoidable.

summer orbit
#

yeah but that's the old way and you can hit real issues when you attach the card if the bank requires 3DS for example

dusky cloud
#

just for my own, more complete understanding: are you saying there was obscure cases - such as a card's bank requiring 3DS - where 3DS must occur at the time the customer associates a card with Stripe/our merchant account?

zealous crane
#

👋 jumping in here and gimme a few mins

dusky cloud
#

ok. thanks for the help @summer orbit

zealous crane
#

are you saying there was obscure cases - such as a card's bank requiring 3DS - where 3DS must occur at the time the customer associates a card with Stripe/our merchant account?
Yes correct

dusky cloud
#

ok. one final question then... is there any way for us to be able to control the 3DS flow so it is shown at checkout-time instead of 'Add a card'-time, like we were doing with the previous SDK?

zealous crane
#

So there is FlowController, for both PaymentIntent and SetupIntent. The Doc above is for SetupIntent

#

You can present the Payment Sheet to only collect payment method details and then later call a confirm method to complete payment in your app’s UI. This is useful if you have a custom buy button or require additional steps after you collect payment details.

#

Let me quick check if we have an example

summer orbit
#

They don't want any SetupIntent though @zealous crane so that won't work right?

#

my read was that you have to complete the callback and give it a client secret

dusky cloud
#

@summer orbit is it fair to tell my product team that the only way to accomplish our goals - while also possibly breaking in obscure scenarios such as a card's bank requiring 3DS - is that we'd need to roll our own, custom 'Add a card' form + implementation?

summer orbit
#

yes

zealous crane
#

Hi @dusky cloud let me confirm a bit here: is that you want to delay 3DS within a checkout process (ie, collect card on a screen, have a few other screen, and then eventually you have a checkout screen where you will display 3DS), or is that you want to separate 3DS (ie, collect card on a screen, then in an unexpected time in the future, will display 3DS)

dusky cloud
#

the last one

#

separate 3DS

#

we implement our own collect card and checkout UXs. they're separate moments in the user experience. and, in order to reduce friction, the product team has asked if it's possible to present 3DS flow during checkout instead of collect card.

#

at the moment, we're using stock Stripe SDK UI components and it seems like the latest version - PaymentSheet - auto-confirms SetupIntents, triggering 3DS

#

previous SDK versions, however, did not appear to do this, allowing us to accomplish our goals (instead, confirming the PaymentIntent at checkout, in order to trigger 3DS)

zealous crane
#

but are the "separate moments" on the same user session? ie. if you can pass variable between 2 screens

dusky cloud
#

no. it could be different user sessions.

#

consider the scenario where a user signs up to our service, adds a card, walks away for 5 days, then picks up our service, attempts to buy with that card

zealous crane
#

Gotchas, then FlowController doesn't help here. Sorry for the confusion and it goes back to what my colleague says!