Add support to close the loading bottom sheet (google pay)

[drekyyy]

Is your feature request related to a problem? Please describe.
Hey, this is a continuation of https://github.com/Adyen/adyen-flutter/issues/296 where I needed the loading bottom sheet and you helped me out - appreciated again.

But now, Id love an option to close that loading bottom sheet utilizing some method preferably.
It would be helpful because we poll /paymentCapture during 3ds flow for few edge cases and Id really like to have the freedom to close the loading sheet when it fits the flow the best.

Why we poll payment capture during 3ds?
It solves our issue where user, upon entering 3ds redirect webpage and providing a password (doesnt matter if correct) is prompted with back to the app redirection and sometimes, instead of one, has two 'same' apps to choose from - I cant really find a solution to this problem, only one of those apps will return the user back to the app, the other one is a 'ghost' and will result in no action, and upon manually closing the page, we get no result from the component to check if the payment was in fact finished or not.

Flutter 3.13.9, Android 14

Please let me know if you would introduce a method to close the loading bottom sheet for GPay. And any feedback regarding the 'two apps' issue is also welcome.

Describe the solution you'd like
Preferably a method that closes the loading bottom sheet

[Robert-SD]

Hi @drekyyy,
Thanks again for your suggestion. I really appreciate your and your teams regular feedback and will discuss the idea with the Android team.
Maybe we can work around the selection picker without using a callback in the meantime. The first impression I have seeing the 'two apps' selector, is regarding the returnUrl and the specified intent filter in your Manifest file of the Android layer.
Do you use flavors and have a "demo/test" and "live" app that both define an intent filter? So you have two apps installed on the device being capable of handling the returnURL intent. In the example app we define the host (applicationId) and an additional path. Does it look similar to your configuration?

[drekyyy]

Hey @Robert-SD
Thanks for quick reply as usual - as per flavors, they aren't implemented in the app. I tried messing with intent-filter but to no success, I will keep searching for a fix though.

Can you let me know when can we expect a new package version containing this gpay fix? https://github.com/Adyen/adyen-flutter/pull/298

[camil-adyen]

Hi @drekyyy, due to peak season and some other features that are still in development we are planning to release v1.2.0 in the first week of January. That release will also include the fix discussed in this issue. We hope that works for you!

[kaczmarzk]

Hi, I'm back to you with my thoughts on these two intents. @camil-adyen @Robert-SD

At some time when we bump a library, a duplicated instance started to show up.
On logcat we can see that first instance is dropin.internal.ui.DropInActivity from SDK, second one is our app.
And exactly in this order you can choose the correct one.

2024-12-04 17:36:07.258 10042-10042 ResolverListAdapter  system I  Add DisplayResolveInfo component: ComponentInfo{pl.lot.mobile/com.adyen.checkout.dropin.internal.ui.DropInActivity}, intent component: ComponentInfo{pl.lot.mobile/com.adyen.checkout.dropin.internal.ui.DropInActivity}
2024-12-04 17:36:07.258 10042-10042 ResolverListAdapter. system I  Add DisplayResolveInfo component: ComponentInfo{pl.lot.mobile/pl.lot.mobile.MainActivity}, intent component: ComponentInfo{pl.lot.mobile/pl.lot.mobile.MainActivity}

I noticed a missing path parameter between our intent and the one in example app, but.
After the addition, the second instance actually stopped showing, but the return to the application also stopped working.

---

Out current implementation

intent

<intent-filter android:autoVerify="true">
       <action android:name="android.intent.action.VIEW"/>
       <category android:name="android.intent.category.DEFAULT"/>
       <category android:name="android.intent.category.BROWSABLE"/>
       <data android:host="{my.app.id}" android:scheme="adyencheckout"/>
</intent-filter>

return-url

adyencheckout://{my.app.id}

---

Do you have any idea what the issue is here?
I understand that I should add this missing parameter, but then how to fix the fact that the application is not receiving this intent? (card component still is in loading state and there is no onAdditionalDetails callback).

[Robert-SD]

Hi @kaczmarzk and @drekyyy,
Apologies that the intent filter setup is not super clear. I will iterate on the documentation and explain it in more detail.

Your returnUrl would explain where the "second" intent filter came from. As you correctly outlined, Drop-In ships with an intent filter out of the box. So there is no need to define one when using this integration. It listens to the combination of adyencheckout (scheme) + {my.app.id} (host) without a path. Using adyencheckout://{my.app.id} will always trigger the listener of the DropInActivity.

For components, it is necessary to define an own intent filter to avoid involving the DropInActivity. This gives you full control over the parameter names. When using our example values like adyencheckout combined with {my.app.id}, a path is always required. It has to be the combination of: adyencheckout + {my.app.id} + /a_custom_value (the path).
In theory you can use any scheme value you want because you control the intent listener. This would omit defining a path. Please don’t forget to adjust the iOS custom URL scheme as well when changing the scheme value on Android.

But lets keep your already defined values. So your intent filter should look like this:

intent-filter

<intent-filter android:autoVerify="true">
       <action android:name="android.intent.action.VIEW"/>
       <category android:name="android.intent.category.DEFAULT"/>
       <category android:name="android.intent.category.BROWSABLE"/>
       <data android:host="{my.app.id}" android:scheme="adyencheckout" android:path="/adyenPayment"/>
</intent-filter>

But we also need to make sure that your /payments request sends a returnUrl that also contains the path.
This might be the missing part.

return-url

adyencheckout://{my.app.id}/adyenPayment

Please let me know if the card component finishes and the onAdditionalDetails is being made.

[kaczmarzk]

Hi, after the corrections android actually worked as we expected.

On the iOS side, is there also a predictable returnUrl?
There we have the problem that after entering the wrong card details, or the wrong inupt on this test 3DS website (redirect).
The modal doesn't close even though onAdditionalDetails is executing in background.
When typing everything correctly the modal closes.

{my.app.id}://payment/return

I would also add that we have given a separate returnUrl per system so we don't have to have them identical.
Doesn't RedirectComponent expect specific path like below?

adyencheckout://{my.app.id}/adyenPayment

[Robert-SD]

@kaczmarzk,
Thanks for sharing. Thats nice to hear that it works on Android!

For iOS there is no need to define a path at all. The path is only being needed to work around the DropInActivity when using adyencheckout as scheme on Android. So for Android and redirectComponent it is necessary to define and provide the path.
Using two different returnUrls (one for each platform) should be fine. Could you share a video of the behavior of iOS? Please feel to send me an email if you do not want to share it publicly here.

[kaczmarzk]

After adding a missing Finished(resultCode: “Refused”) from the onAdditionalDetails it worked.
On iOS modal was not closed by deeplink/intent itself as it works on android, you have to return valid PaymentEvent.
I think it would be great to add this to the documentation, it is quite confusing 😀

[Robert-SD]

Thanks for letting us know that using Finished worked and resolved the closing! 🙂
Getting to know your problem and receiving your feedback is really helpful. We already planned to iterate on our documentation. Please let me know when you have any further questions.
Although it has been resolved, I would like to keep this issue open because the feature request might be a good addition in future.