'Adyencheckout' links are blocked

[neil-showpo]

Describe the Bug
Hi we are currently experiencing issues when using Adyen in Android when the payment method needs a return_url (example is Klarna payover time). We are getting an error message stating that the scheme for the return_url is blocked after completing the payment and trying to redirect back to the app. We are using the return url generate using RedirectComponent.getReturnUrl(this);

To Reproduce
Do a checkout using drop-in that requires are return_url. Example would be Klarna Pay Over time.

Device used:

• Xiaomi Mi 10T Pro - Android 12 SKQ1.211006.001
• Galaxy J7 (2016), Android 8.1.0
• Redmi Note 8 Pro, Android 11

Additional Information:
There are some devices which the issue cannot be replicated but a significant amount of the devices we used for testing return with the link blocked error.

[OscarSpruit]

Hi, thank you for opening this issue. Could you run the command below to verify if the deeplink is actually working?

adb shell am start -W -a android.intent.action.VIEW -d "adyencheckout://com.adyen.checkout.example"

Also, could you provide more details about the browsers and their versions that are being used? It could be a specific version of a browser that doesn't allow the way in which the redirect is performed anymore.

[neil-showpo]

Hi, ah yes we can confirm that the deeplink is working because we were able to do successful checkout on some of our devices. However, for most of the devices we tried we encountered the error above.

We are unsure of the browser used since we are using Drop-in but it seems to be a webview powered by Chrome. We followed the Adyen Drop-in guide step by step and it was working before but suddenly we encountered the problem that the link is blocked.

[OscarSpruit]

Can you try debugging the webview and share the logs? In this article they explain how to do it.

[neil-showpo]

Hi @OscarSpruit was just able to confirm the browser and versions being used.

It is failing on the following devices:

• Xiaomi Mi 10T Pro - Android 12 SKQ1.211006.001
  Browser: Chrome 102.0.5005.78
• Galaxy J7 (2016), Android 8.1.0
  Browser: Chrome 102.0.5005.78
• Redmi Note 8 Pro, Android 11
  Browser: Chrome 102.0.5005.78

The redirect was working on devices with older chrome versions:

• Huawei Android 7
  Browser: Chrome 92.0.4515.159
• Emulator Android 11
  Browser: Chrome 83.0.4103.106

Is there a workaround for this issue at the moment?

[OscarSpruit]

Thanks! It indeed seems to be an issue with certain chrome versions. We are still investigating what exactly causes it, so no workaround for now. However, I read in a chromium issue thread that clearing the cache/app data of the Chrome app sometimes fixes the problem.

[crherman7]

@neil-showpo @OscarSpruit this is a current Chrome Custom Tabs issue https://bugs.chromium.org/p/chromium/issues/detail?id=1323163&q=ERR_UNKNOWN_URL_SCHEME&can=2. This started to break after Chrome version 100.0.4896.127.

This does highlight the a tightly coupled issue with Custom Tabs - maybe we could provide an override where it could just open in the default browser as it's not an issue with Chrome it's an issue with the CustomTabs extension. This would allow apps to safely continue to use Redirect Components when Chrome Custom Tabs breaks but I understand this is likely a rare situation.

[jreij]

Hi @neil-showpo. Did you notice anything particular about the redirects that failed? For example did the redirect take a long time before it eventually failed, or did it happen in the background, or does it only happen in custom tabs but not in Chrome, etc. We're struggling to reproduce it consistently so I was wondering if you have any more input. Can you maybe share a screen recording as well? Thanks again for helping investigate this!

[neil-showpo]

Hi @jreij we seem to encounter it consistently when making US Klarna pay over time payments on the test environment. When making Klarna pay over time payments on other currencies like AUD it seems to work normally. The error seems to happen only on the Custom Tabs after finishing the payment process and when it is trying to get back to the app using the return url. We are just using the default Drop-in implementation of the Adyen SDK.

We'll try to post a recording of the issue later.

[jreij]

Thanks @neil-showpo for the details. So far we did some thorough investigation and we think that as @crherman7 suggested (thanks as well!) this is mainly an issue caused by Chromium and Custom Tabs. Currently our interpretation of the issue is this:

Background

The issue occurs in the following flow:

1. Merchant redirects to the issuer inside Custom Tabs.
2. Issuer redirects back to the merchant’s app using a deeplink. The redirect fails here.

It seems to have started happening with Chrome version 100.0.4896.127 (see bug tracker).

Solution directions

• Why do we see this issue: most likely, the transition inside step 2 takes more than 5 seconds which causes a timeout. This timeframe seems to be new timeout that comes with the above Chrome version (previously it was 10 seconds). This delay is not caused by us, but calculated between the (i) the last moment that the shopper clicked somewhere in the custom tab, and (ii) the moment when the final redirect to the merchant app occurs. This seems a new protection measure by Chrome to prevent the shopper being redirected without their consent.
• Possible solution from the shopper: shopper clicks on the 3 dots on the right top corner and clicks on “Open in Browser”. In this case, the redirect should be retried again and might succeed.
• Potential fix: Chrome is hopefully releasing a new version that will revert the timeout to 10 seconds, which reduces the probability of this issue.

[crherman7]

@jreij thanks for the updates and potential solutions outline!

It doesn't seem like the google team has had any success yet solving the issue. Has your team thought about allowing a consumer of the library to pass an override attribute to disable Chrome Custom Tab intent and just use the default browser intent?

[christianfindsen]

We are informing our users about the 3 dots way until Google fixes the issue.

I have tried overriding the Adyen redirect component and disabling the Custom Tab intent with an browser intent and that unfortunately did not resolve the issue and the user would not be able to do the 3 dot solution.

[crherman7]

@christianfindsen how did you go about overriding the Custom Tab Intent?

adyen-android/redirect/src/main/java/com/adyen/checkout/redirect/RedirectUtil.kt

Line 110 in 0cb4505

fun createRedirectIntent(context: Context, uri: Uri): Intent {

did you simply just locally change this logic, re-compile lib and link a as local module?

[jreij]

I think the redirect might get blocked with Chrome as well as Custom tabs, however what the 3 dots action does is simply retry the redirect which might solve the issue.

Another thing we are doing is to reach out to the payment methods (for example Klarna) to figure out if anything can be done on their end to solve this, especially if the "5 seconds" timeout is indeed the root cause of the issue. Will keep you posted 👍

[christianfindsen]

@christianfindsen how did you go about overriding the Custom Tab Intent?

adyen-android/redirect/src/main/java/com/adyen/checkout/redirect/RedirectUtil.kt

Line 110 in 0cb4505

fun createRedirectIntent(context: Context, uri: Uri): Intent {

did you simply just locally change this logic, re-compile lib and link a as local module?

No I copied the needed classes into my local project and then added my own logic.

But as @jreij mentions is that both are blocked and the 3 dot solution is retying the redirect, so it doesn't work.

Hopefully we will see some fixes in the near future.

[christianfindsen]

Hi, @jreij Hope you guys are doing well.

Are you following the issue on the bug that you linked? It seems like it might be another Chrome issue with a potential workaround on the glue page.

We are still seeing this issue with Twint.

[jreij]

Hi @christianfindsen , thanks for the update! We are looking into it indeed, so far we still the the fix has to be done on the payment methods' side (Klarna, Twint, etc.) but we are investigating with them and internally as well on how to solve this.

[jreij]

Hi again everyone, are you still facing this issue? And how frequently compared to before? We saw a few updates on Chromium that tried to mitigate it but we're not sure how effective they are. We'd appreciate it if you have some recent feedback 🙂

[christianfindsen]

Hi @jreij, we are still facing the issue with Twint. Since 28/10 we have even dropped 7% more in complete purchases without any related app released from our side.

I just did a test today with the Twint test app and saw a minor popup view in the top when trying to redirect back to the app and that worked fine but I do see an issue here that if the user do not click on that within ~5 sec the view fades and you have no way to navigate back.

Not sure if they have rolled this out to everyone as we are still getting user complaints in the affected markets.

[jreij]

Thanks a lot @christianfindsen for your feedback, very helpful as always! I will forward this internally and see how we can follow up with Twint.

[jreij]

Do you have any data about Klarna or any other payment methods as well?

[christianfindsen]

We are only having issues with Twint. Other 3rd party payments that has redirects involved are performing as good as they can.

[plastiv]

Hi again everyone, are you still facing this issue? And how frequently compared to before? We saw a few updates on Chromium that tried to mitigate it but we're not sure how effective they are. We'd appreciate it if you have some recent feedback 🙂

Hi @jreij I can confirm that we still see an issue with Klarna payment and RedirectComponent integration.

When CCT is opened after the payment navigation back to the app with the deep link is blocked by the browser. The difference now with last year is that there is also a popup from the browser with a "Continue" button. But this popup disappears after a few seconds so if the user misses it the payment flow is still broken.

[jreij]

Thanks for reporting this @plastiv !

[christianfindsen]

Hi @jreij. Just got back from a long overdue vacation 👯

On our end we are not seeing the issue anymore on the affected markets and we are back to the expected conversion.