🐛 Crash during 3DS2 verification

[dhartwich1991]

Describe the bug Our app crashes sometimes during the 3DS2 verification. In this line https://github.com/Adyen/adyen-android/blob/5.3.0/components-core/src/main/java/com/adyen/checkout/components/core/CheckoutConfiguration.kt#L123 probably originating from this unchecked cast exception.

Stacktrace:

java.lang.ClassCastException - Q3.a cannot be cast to q3.a

com.adyen.checkout.adyen3ds2.Adyen3DS2ConfigurationKt.getAdyen3DS2Configuration (Adyen3DS2Configuration.kt:145)
com.adyen.checkout.adyen3ds2.internal.ui.model.Adyen3DS2ComponentParamsMapper.mapToParams (Adyen3DS2ComponentParamsMapper.java:35)
com.adyen.checkout.adyen3ds2.internal.provider.Adyen3DS2ComponentProvider.getDelegate (Adyen3DS2ComponentProvider.kt:83)
com.adyen.checkout.adyen3ds2.internal.provider.Adyen3DS2ComponentProvider.getDelegate (Adyen3DS2ComponentProvider.kt:48)
com.adyen.checkout.action.core.internal.ui.ActionDelegateProvider.getDelegate (ActionDelegateProvider.java:53)
com.adyen.checkout.action.core.internal.ui.DefaultGenericActionDelegate.handleAction (DefaultGenericActionDelegate.kt:111)
com.adyen.checkout.action.core.GenericActionComponent.handleAction (GenericActionComponent.java:66)

From our point of view this looks like a problem with obfuscation (maybe), but as you stated that all the rules are coming from the SDK directly we didn't add any

To Reproduce Steps to reproduce the behavior: We initiated a payment in our app and ran into the 3DS2 verification. Then the crash occured.

Expected behavior No crashes :)

Screenshots If applicable, add screenshots to help explain your problem.

Smartphone (please complete the following information):

• Device: Pixel 4a
• OS: Android 13
• Version: Adyen SDK 5.3.1

Additional context Add any other context about the problem here.

[OscarSpruit]

Hi @dhartwich1991, thank you for opening this issue! Could you provide the code used to create the configuration(s) and how you pass it to drop-in or components? This would help us with reproducing the issue

[dhartwich1991]

Hey Oscar! Thanks for getting back to me, here is the code that we use to create the configs:

private fun initAdyenComponents(clientKey: String) {
        try {
            val analyticsConfig = AnalyticsConfiguration(level = AnalyticsLevel.NONE)

            val threeDs2Config =
                Adyen3DS2Configuration.Builder(
                    shopperLocale = requireContext().locale,
                    environment = adyenEnvironment,
                    clientKey = clientKey,
                )
                    .setAnalyticsConfiguration(analyticsConfig) // To be sure, pass here as well, not just in genericConfig.
                    .setThreeDSRequestorAppURL(requireContext().assembleAppLink(path = "/adyen3ds2"))
                    .build()
            val redirectConfig =
                RedirectConfiguration.Builder(
                    requireContext().locale,
                    adyenEnvironment,
                    clientKey,
                )
                    .setAnalyticsConfiguration(analyticsConfig) // To be sure, pass here as well, not just in genericConfig.
                    .build()
            val genericConfig =
                GenericActionConfiguration.Builder(
                    shopperLocale = requireContext().locale,
                    environment = adyenEnvironment,
                    clientKey = clientKey,
                )
                    .add3ds2ActionConfiguration(threeDs2Config)
                    .addRedirectActionConfiguration(redirectConfig)
                    .setAnalyticsConfiguration(analyticsConfig)
                    .build()
            actionComponent =
                GenericActionComponent.PROVIDER.get(
                    savedStateRegistryOwner = this,
                    viewModelStoreOwner = this,
                    lifecycleOwner = this, // BEWARE!!! Overload with less parameters does `fragment.viewLifecycleOwner` but this a headless Fragment.
                    application = requireActivity().application,
                    configuration = genericConfig,
                    callback = actionComponentCallback,
                )
                    .apply {
                        setOnRedirectListener { setupRedirectResponseTimeoutTimer() }
                    }

Hope this helps 👋 if you need more information please let me know!

Thank you ❤️

[OscarSpruit]

@dhartwich1991 with the exact same setup I'm not able to reproduce it. When you do a clean build without build cache (./gradlew clean assemble --no-build-cache) does the issue persist?

Another option could be to try and use CheckoutConfiguration like this:

val checkoutConfiguration = CheckoutConfiguration(
    shopperLocale = requireContext().locale,
    environment = adyenEnvironment,
    clientKey = clientKey,
    analyticsConfiguration = AnalyticsConfiguration(level = AnalyticsLevel.NONE),
) {
    adyen3DS2 {
        setThreeDSRequestorAppURL(requireContext().assembleAppLink(path = "/adyen3ds2"))
    }
}

val actionComponent = GenericActionComponent.PROVIDER.get(
    savedStateRegistryOwner = this,
    viewModelStoreOwner = this,
    lifecycleOwner = this, // BEWARE!!! Overload with less parameters does `fragment.viewLifecycleOwner` but this a headless Fragment.
    application = requireActivity().application,
    checkoutConfiguration = checkoutConfiguration,
    callback = actionComponentCallback,
)
    .apply {
        setOnRedirectListener { setupRedirectResponseTimeoutTimer() }
    }

We recently introduced this DSL for creating configurations. It saves some duplicated lines (like setAnalyticsConfiguration). It is slightly different under the hood, so maybe it helps

[cc-rock]

We're having the exact same issue, and I went to the bottom of it: the cause is that, inside CheckoutConfiguration.kt, the map of available configuration objects uses the class' simple name as the key, and this of course causes clashes when classes are obfuscated and many of them end up with the same simple name (in the stack trace above, you can see that both classes' simple name is "a"). A workaround that solves it for us is to add the following proguard rule:

-keep class com.adyen.checkout.** extends com.adyen.checkout.components.core.internal.Configuration

but a proper fix would be to change the implementation and use the class full name (including the package) as the key, instead of the simple name.

[OscarSpruit]

@cc-rock thank you very much for the detailed investigation and the workaround! We will look into your proposed fix and try to address the issue as soon as we can.

[OscarSpruit]

Hi @dhartwich1991, we just released 5.4.0 which should fix this issue. Thank you again for the help @cc-rock!

[dhartwich1991]

Hi @dhartwich1991, we just released 5.4.0 which should fix this issue. Thank you again for the help @cc-rock!

Awesome! Thank you so much, both of you <3