3D secure check gets stuck on Android when using sessions.

[todibbang]

Describe the bug
I have moved away from the "Advanced flow: three API requests" and to the session protocol as this is the suggested method for making 3D secure checks work with the app (according to Adyen - Build your integration ) and this appear to works for iOS. But for Android I've experienced a weird interaction between the Adyen library and the App "MitID" that most payment providers in Denmark use to perform the 3D secure check.
On Android the MitID app appears to be opened inside my own app rather than redirected to, and it is not closed after the payment has been accepted, effectively hijacking my app.

Below is a screenshot to illustrate the issue, I've had to gray out the content for privacy purposes but I hope it still makes sense. The body of "My App" is the exact same as that of the "MitID App" and there is no way to navigating back to the real "My App" so I end up with two instances of the MitID App running, one as it's own app and one inside my app. The only way to "fix" it is to close "My App" but this breaks the payment flow.

The implementation
In package.json:
"@adyen/react-native": "^2.7.2"
The Adyen payment components looks like this:

export const AdyenPayment = (props: {
  adyenCheckoutData?: AdyenCheckoutData
  orderId: string
  onCancel: () => void
  onComplete: () => void
  status: OrderStatus | undefined
  countryCode: string | undefined
  paymentAmount: {
    value: number
    currency: string
  }
  showStorePaymentField: boolean
}) => {

  return (
    <AdyenCheckout
      config={{
        clientKey: props.clientId,
        environment: props.live ? 'live-eu' : 'test',
        returnUrl: adyenReturnUrl,
        countryCode: props.countryCode,
        amount: props.paymentAmount,
        applepay: {
          merchantID: props.appleMerchantId,
          merchantName: props.appDisplayName,
        },
        card: {
          showStorePaymentField: props.showStorePaymentField,
          holderNameRequired: true,
        },
        locale: globalLocale,
      }}
      session={props.session}
      onError={(payload: AdyenError, nativeComponent: AdyenComponent) => {
        // ...
      }}
      onComplete={(result: string, nativeComponent: AdyenComponent) => {
        // ...
      }}
    >
      <Inner />
    </AdyenCheckout>
  )
}

const Inner = () => {
  const [started, setStarted] = useState<boolean>(false)
  const { start, paymentMethods } = useAdyenCheckout()

  useEffect(() => {
    if (paymentMethods?.paymentMethods == undefined) return
    setStarted(true)
    if (start && !started) {
      start('dropIn')
    }
  }, [start, paymentMethods?.paymentMethods])

  return <ActivityIndicator />
}

MainActivity.kt looks like this:

import android.os.Bundle

class MainActivity : ReactActivity() {

...
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(null)
    AdyenCheckout.setLauncherActivity(this)
  }
}

It is not clear to me how the returnUrl should be filled out in this case, and maybe this is causing the issue? The documentation for the returnURL says:
"Custom URL scheme of your iOS app. This value is overridden for Android by AdyenCheckout. You can also send this property from your backend.".
According to the documentation then filling out <data android:scheme="myapp" android:path="/payment" /> is only necessary "For standalone components", so I've not done that.

Summary
I realise that this might be hard to reproduce, but I hope that the nature of the issue is clear. I don't know if it's common for apps to open each other in this way, and maybe this protocol is used by other 3D secure apps other than MitID. It might be a result of how the Android implementation handles 3D verification. According to this post Stack Overflow embedded web views are no longer supported for MitID on Android and the login flow must use Chrome Custom Tabs (or an external browser) - I'm not sure what the Android implementation does in this case.

I'll look forward to your reply, thank you in advance :)

[descorp]

Hey @todibbang

Thank you for feedback!
The returnUrl is indeed very confusing and not well documented part of of our SDK.

In the nutshell, Android DropIn as an Activity has own returnUrl. To get this value on sessions flow use AdyenDropIn.getReturnURL() see example.

[todibbang]

Hi @descorp, thank you for your reply.
I've implemented your proposed fix and tested it, but it does not resolve the issue. I've documented the entire flow to demonstrate the issue as it appears as if no redirect is made at all. The entire verification happens inside "My App", even the part that is actually the other third party MitID app which cause me to believe that it is unable to redirect back to the Android app, even with the correct redirectUrl, as it's all running in the same app instance.

The flow

1 - Adyen Dropin started from the checkout screen of My App

2 - Adyen Dropin loading, Card info entered

3 - Adyen Dropin asks to verify payment

4 - 'Open MitID app' (Åben MitID app) is clicked

5 - MitID app is navigated to inside 'My App' - it is not redirected to. I have the MitID app installed on my phone but it has not opened the app the way i would expect, is has navigated to the app inside 'My App' as if it was a Screen.

6 - MitID app - payment verified

7 - MitID app clearly open inside 'My App' - hence it was not redirected to

8 - Opening 'My App' continues to show 'MitID' - i did however find that if I slide the screen to the right i can navigate back to the screen in step 4, again making it behave as a Screen inside my app rather than a seperat app that was navigated to

Summary

I also use the MitID app for other kinds of verification in my app, unrelated to the payment flow, and in this case the MitID app is indeed navigated to in the traditional sense.

Furthermore, clicking the 'Continue' (Fortsæt) button first does nothing even though the helper text says to click 'Open MitID app' or 'Continue' which is pretty confusing.

But it does not seem to be related to the redirectURL being incorrect, but instead a side effect of how the Adyen SDK redirects/navigates to the MitID app.

But I'll look forward to hearing your thoughts.

[descorp]

Hey @todibbang

This is interesting indeed. I'll share this with https://github.com/Adyen/adyen-3ds2-android team

You can also reach out Support Team via Customer Area or via email: support@adyen.com and share full video and PSP references in a secure manner (make sure to disclose any personal or payment information). Please mention this ticket in your inquiry.

[descorp]

I wonder if the same flow will be observed in case of Web Redirect. Could you try omitting threeDS2SdkVersion parameter? (this is not a solution, but experiment).

[todibbang]

I do not include the threeDS2SdkVersion right now, should I try and include it and what should it be?

[descorp]

I have moved away from the "Advanced flow: three API requests" and to the session protocol

My theory is that previously you were using "Web Redirect 3DS" and now with the sessions you are receiving "Native 3DS" flow. Sessions flow does include threeDS2SdkVersion by default.

You can try playing with authenticationData.threeDSRequestData.nativeThreeDS - preferred/disabled on your backend's \sessions API request to try both flows. One should trigger a web page (ChromeTabs/Safari); the other - a custom view (the one you shared on screenshots).

[todibbang]

The 3DS didn't work with the "Advanced flow" either, and when i looked into the documentation it said to use sessions, so that's how I ended up here :)

But I'll try and and trigger the Web Redirect flow by setting authenticationData.threeDSRequestData.nativeThreeDS to disabled, and I will not set the threeDS2SdkVersion, as the session handles this automatically - correct?

This is the code from the api after implementing your suggestion:

const response = await checkOutApi.PaymentsApi.sessions({
        amount: {
          currency: props.currency,
          value: props.amount,
        },
        reference: createAdyenReference(transactionId),
        merchantAccount: merchantId,
        countryCode: props.countryCode,
        returnUrl: props.returnUrl,
        metadata: this.buildMetaData({
          transaction: transaction,
          userId: props.customer?.userId,
          customerId: props.customer?.customerId,
        }),
        shopperInteraction:
          CreateCheckoutSessionRequest.ShopperInteractionEnum.Ecommerce,
        captureDelayHours: captureManually ? undefined : 0,
        additionalData: captureManually ? { manualCapture: 'true' } : undefined,
        shopperReference: props.customer?.customerId,
        shopperStatement: props.paymentSetting?.shopperStatement ?? undefined,
        blockedPaymentMethods:
          props.paymentSetting?.blockedPaymentMethods ?? undefined,
        shopperEmail: props.email,
        channel:
          props.platform == 'android'
            ? CreateCheckoutSessionRequest.ChannelEnum.Android
            : props.platform == 'ios'
            ? CreateCheckoutSessionRequest.ChannelEnum.IOs
            : CreateCheckoutSessionRequest.ChannelEnum.Web,
        authenticationData:
          props.platform == 'android'
            ? {
                threeDSRequestData: {
                  nativeThreeDS: ThreeDSRequestData.NativeThreeDSEnum.Disabled,
                },
              }
            : undefined,
      })

[descorp]

3DS didn't work with the "Advanced flow"

Could be due to incorrect returnUrl ?

This is the code from the api after implementing your suggestion:

Seems valid.

[todibbang]

I have tested having nativeThreeDS both set to Disabled and Preferred when creating the session in the API. When Preferred I get the same behaviour as before where the MitID app is opened inside my own app.
When I set it to Disabled, which according to the documentation should: 'Use the redirect 3D Secure authentication flow', then I get an Authentication failed webhook update, and no 3DS is happening in the client, indicating the it's unable to start the 'redirect 3D Secure authentication flow'. I have verified that the redirectUrl that is used to create the session in the api is indeed the result of calling the AdyenDropIn.getReturnURL() as previously suggested.
What could be the reason as to why the redirect 3DS isn't working for sessions on android in my setup?

[descorp]

Thank you for research @todibbang

why the redirect 3DS isn't working for sessions on android in my setup?

This is interesting case, indeed.
So far my theory - problem is on this the issuer side. I am in contact with 3DS2 team, will keep you posted.

Have you already reached out Support Team?
It would help if you can provide them with videos and PSP references of both flows (Disabled and Preferred )