adyen-android icon indicating copy to clipboard operation
adyen-android copied to clipboard

[v5.2.0] Request for clarification: No 3DS dialog shown when using session payments & drop-in

Open JakeSteam opened this issue 1 year ago • 2 comments

Hey, not necessarily a bug report, more of an "is this a bug" report.

Context

I am migrating an app from 4.X with components and advanced flow, to 5.2.0 with drop-in and sessions. Payments all seem to work, however when attempting to make a payment using sessions, no 3DS verification dialog / redirect is shown for 3DS enabled cards.

This occurs for brand new accounts, and whilst I'm happy it's working... I'd like to check it's actually working correctly, perhaps by forcing a "worst case" 3DS scenario!

Confusion

This documentation seems to state some extra configuration is required, but it only applies to "Advanced flow".

This guide is for integrations using Drop-in v5.0.0 with the Advanced flow.

Similarly, this documentation seems to imply 3DS2 might occur without any user interaction at all, which is astonishing if true. Is there a way to force a challenge flow?

In a frictionless flow, the acquirer, issuer, and card scheme exchange all necessary information in the background through passive authentication using the shopper's device fingerprint. The transaction is completed without further shopper interaction.

I don't currently have access to the backend configuration, but essentially wanted to check not seeing any dialog yet everything just working is... all OK? Apologies for the vagueness!

Supporting evidence

Drop-in initialising:

@Composable
fun CheckoutDropIn(
    context: Context,
    sessionDropInCallback: SessionDropInCallback,
    checkoutSession: CheckoutSession
) {
    val dropInLauncher = rememberLauncherForDropInResult(sessionDropInCallback)
    SideEffect {
        DropIn.startPayment(
            context,
            dropInLauncher,
            checkoutSession,
            PaymentManager.checkoutConfiguration
        )
    }
}

Note: All parameters are created as per docs, e.g. CheckoutSessionProvider.createSession for the session.

Checkout configuration:

        private val cardConfiguration = CardConfiguration
            .Builder(Locale.getDefault(), env, key)
            .setHolderNameRequired(true)
            .build()

        val checkoutConfiguration = DropInConfiguration.Builder(Locale.getDefault(), env, key)
            .addCardConfiguration(cardConfiguration)
            .build()

JakeSteam avatar Mar 27 '24 15:03 JakeSteam

Hi @JakeSteam, thank you for the detailed explanation of your question and for reviewing our documentation.

It's possible for 3DS2 to occur without any user interaction. However, I understand your concern that without adding support for 3DS, if user interaction is necessary, the payment could fail.

Here's what I suggest:

  • Include authenticationData when making a request to the /sessions and /payments endpoints from your backend. By using a combination of attemptAuthentication, authenticationOnly, and threeDSRequestData, you can achieve the desired behavior. Additionally, you could specify nativeThreeDS as preferred if you want to test the native 3DS2 flow.

Could you please try this approach and let me know if it worked for you?

araratthehero avatar Mar 28 '24 13:03 araratthehero

@araratthehero Thanks for the quick reply, those look good!

It's a holiday here until next Tuesday, so will give those a try and get back to you next week 🙂

JakeSteam avatar Mar 28 '24 22:03 JakeSteam

Hi @JakeSteam , did you have the chance to try the suggested solution?

jreij avatar May 06 '24 12:05 jreij

@jreij Apologies! Yes, using the 3DS test cards and tweaking a few things on our backend resolved the issue, and the implementation worked perfectly 🙂

JakeSteam avatar May 06 '24 15:05 JakeSteam