[BUG] secure payment open for a sec and closed without user interaction

[TomerBitan24]

Hi, we had this ticket: here you can find all the previous details: https://github.com/stripe/stripe-android/issues/7937

we have one more question about this issue, if we want to leave the request_three_d_secure with the value any, is there other option to make sure it's not open the secure payment screen when it's not needed? because in ios they have different behvior, it's not open the screen in this case(when we tried to add the same test card without 3ds - 4242 card)

this flow on android is weird because it try to open and close the secure payment screen without any user interaction:

android flow: https://github.com/stripe/stripe-android/assets/84137123/e43a99c6-725c-4e02-8317-c04a56689713

here you can see the attached video of ios (same flow): https://github.com/stripe/stripe-android/assets/84137123/b7d04b4a-2384-44e8-b1fc-0a43e8a4115d

[seanzhang-stripe]

Hi @TomerBitan24 When you set request_three_d_secure to any, it indicates that 3DS is required for this payment and therefore your customer will be asked to perform a 3DS authentication.

As I explained in https://github.com/stripe/stripe-android/issues/7937, you should remove this param from your request if this is not something that you want.

Can you share with the respective PaymentIntent IDs that you passed to your Android and iOS integration?

[TomVia]

Hi @seanzhang-stripe,

Can you explain why we experience differences in the flow between Android and iOS? The flag is the same in both cases, the card we use is the same and yet, we see the secure payment screen opens and closes automatically on Android but not on iOS (see attached videos).

PaymentIntent IDs are: Android: seti_1OlGzzGE03DL3EHwjstujSU4 iOS: seti_1OmZspGE03DL3EHw6dL38MjN_secret_PbnTbhn7PwYlQ2sKxk8w8TzQpiko4Js Thank you.

[seanzhang-stripe]

Hi @TomVia, I have checked the underlying SetupAttempt objects for both flows (setatt_1OmZthGE03DL3EHwyDVk1J0P and setatt_1OlH00GE03DL3EHwUCPlFrzq). The three_d_secure.result of both SetupAttempts is attempt_acknowledged, which means

The issuing bank does not support 3D Secure, has not set up 3D Secure for the card, or is experiencing an outage. No authentication was performed, but the card network has provided proof of the attempt.

In most cases the attempt qualifies for liability shift and it is safe to make a charge.

The 4242 card that you used during the test doesn't support 3DS, but you were enforcing 3DS by setting request_three_d_secure to any, and that explains why the 3DS authentication page isn't opened fully in both Android and iOS, and three_d_secure.result is attempt_acknowledged. Having said that, I agree that the behaviour between Android and iOS is inconsistent, and I'd put it to our internal backlog.

[seanzhang-stripe]

Internal backlog ID: RUN_MOBILESDK-2965

[TomVia]

Thank you for the answer @seanzhang-stripe Can you give a rough timeline on when this inconsistency will be addressed ?

[TomVia]

@seanzhang-stripe just to make sure - the expected behaviour is what we see on iOS correct?

[seanzhang-stripe]

We don't have a timeline for this task yet, and we will prioritize our tasks based on their urgency and importance. Please share any additional details that can help us in understanding the potential impact this feature may have on your application.

[tomgolan]

@seanzhang-stripe Can you confirm that the expected behaviour is the flow we see on iOS (with no authentication page opened)?

[jaynewstrom-stripe]

It is a difference in UX, but we have many variables that drive these behaviors.

Closing this noting it's an expected difference.