Payments: redirectURL behaviour

[KestasVenslauskas]

I'm having an issue understanding the correct redirectURL behaviour for payments.

DeepLink way

Let's say I have a deepLink in my app "myApp://app/payment-confirm"

1. I will set KevinPaymentsConfig redirectURL to "myApp://app/payment-confirm"
2. I will initiate kevin bank payment with the same redirectURL.

On android:
redirectURL gets ignored and just a simple callback is called on the apps flutter code.
OK if we rely on app pinging the backend for a successful payment

On iOS
Kevin SDK hangs on last step where it says "Redirecting to..." after payment is complete. I think it because it's not valid link like "https://....".
NOT OK!!! Even if the payment was complete I can only close the dialog after which I will receive a callback with "payment was cancelled" status

Now the other part with valid link

1. I will set KevinPaymentsConfig redirectURL to "localhost:3000/payment-confirm"
2. I will initiate kevin bank payment with the same redirectURL.

On android:
redirectURL gets ignored and just a simple callback is called on the app.
OK if we rely on app pinging the backend for a successful payment

On iOS
redirectURL gets called with correct query parameters I also see website flashing for a few miliseconds and then the callback on flutter side is called. -
Perfect

Can we have a consistency here?
I would prefer having our backend as a redirectUrl consumer instead of deep link.
But I want kevin-flutter SDK to be responsable for calling it on Android aswell.

P.S. Ofcourse I can set redirectUrl to "https://www.google.com" then totaly ignore it and only operate from flutter callback. But I don't think that this is the prefered flow because going back to the app causes additional steps to be taken. More steps = more ways for a crashes to happen. And I think developers would feel safer if your SDK would ping redirectURL instead relying on developers to have a crash free process to notify the backend sistems...

EDIT: Added videos below

[KestasVenslauskas]

iOS with deepLink:

kevin_flutter_ios_deep_link.mp4

iOS with valid link:

kevin_flutter_ios_valid_link.mp4

Android (works same - ignores the redirectURL both ways)

kevin_flutter_android.mp4

[antons-zubkovs]

@KestasVenslauskas the issue is that callbackUrl is intended for the client (app), and not to be called later to inform your BE. The callbackUrl, which you provide during payment/linking initialisation on your BE side, is called after payment/linking flow is completed, having some operation's status payload. That payload is understood and digested by our native SDK and the result is emitted to you via flutter plugin. We don't really support you desired behaviour for external URL to be called and app to be opened after flow completion. The best solution is to call your BE after result is collected from flutter plugin.

If you really want to achieve that behaviour, you can try to set callback URL A during initialisation on BE, and callback B during kevin. SDK initialisation. Then your callback A will be called after flow completion, after that you have to redirect to callback B (passing received payload), so that the app could be opened automatically. Though we do not support that flow.

Worth noting, that Android app could not be opened automatically, when having http/s scheme for deep link, unless your app is approved for the specific domain contained in that web intent. More on that here.

Additionally, we added an option to set different callbackUrls for iOS/Android in new versions of our plugins:

kevin_flutter_core: ^1.0.3
kevin_flutter_accounts: ^1.0.2
kevin_flutter_in_app_payments: ^1.0.1

const KevinAccountsConfiguration(
      callbackUrl: KevinCallbackUrl(
        android: _kevinAccountsCallbackUrlAndroid,
        ios: _kevinAccountsCallbackUrlIos,
      ),
    ),

That comes in handy when you want to set non-http/s callbackUrl for Android and http/s callbackUrl for iOS.

[KestasVenslauskas]

@antons-zubkovs OK, but this way iOS will ping BE once more because as I mentioned it open it in kevinSDK as a webview blinks for few MS and goes back to the app. It's fine by us but would prefer same flow for both platforms.

[antons-zubkovs]

@KestasVenslauskas as I mentioned above, that behaviour is not really supported and designed by us, so you will need to introduce some workarounds. You can try to set different callbackUrls for Android, but use same urls for iOS, for example.

[KestasVenslauskas]

@antons-zubkovs

The callbackUrl, which you provide during payment/linking initialisation on your BE side, is called after payment/linking flow is completed, having some operation's status payload

It's not called on android it's completely ignored. Where on iOS it is called because iOS always makes a call to to callbackUrls at the end of the payment.

Using different callbackUrls for initialization & mobile SDK works if we redirect back to initialization callbackUrl. But this is still a workaround. So there is no out-of-the-box trigger that Kevin would send to our BE informing about successful payment?

[KestasVenslauskas]

@antons-zubkovs

https://api-reference.kevin.eu/public/platform/v0.2#tag/Payment-Initiation-Service/operation/initiatePayment
I think we can ignore Redirect-URL as it's used on client only for redirecting back to the calling app.
What I missed is Webhook-URL which should do the work I need.

[antons-zubkovs]

@KestasVenslauskas it's not ignored on Android, it is being intercepted. If your payment/linking flow is happening inside the kevin's WebView, then WebView listens to current URL changes, and, in case of callbackUrl (which you have set during kevin's initialisation), it prevents WebView from navigating to that URL and takes it's payload to digest and send you the result.

I believe, that Webhook-URL is indeed what you might be looking for.

[KestasVenslauskas]

@antons-zubkovs Hi again. As we are starting actual implementation of kevinPayments we face the same issue that iOS does not intercept custom schemas like kevin://... and only works http or https is this entended behaviour? As I see you workaround this issue aswell in example app. Is this mentioned somewhere in documentation?

[antons-zubkovs]

@KestasVenslauskas hello, we went with Universal Links for iOS, because it's:

• Apple suggested way
• We faced some issues with custom schemes

That's why there is an option in the plugin to define different callbacks for android/iOS. You may try to handle it via custom schemes, but we personally use https schemes for iOS.

For android to use https scheme, your app has to be approved for the specific domain contained in that web intent (according to docs).

[KestasVenslauskas]

@antons-zubkovs For now we will stick to the same implementation as in the example app until we have our website ready for universal links. We didn't managed to make it work with custom schemes on iOS. Please mention this somewhere in your documentation so there will be no more confusion for other devs.