App2app redirect: the correct way to handle it
Product development is a key part of Salt Edge’s success. All new technologies and features are being tested internally and by end-users, which gives us an opportunity to improve and learn from their direct feedback. Sharing is caring. Hence, we find it essential to share our experience in implementing app2app redirect from/to native mobile applications. An internal investigation showed that the obstacles faced during app2app redirect, which are considered ordinary, actually have many nuances and conditions.
We’ll explain the found solutions based on Salt Edge’s Open Banking Gateway, a service that enables third party providers (TPPs) to get instant access to banks across the EU for account information and payment initiation purposes.
The app2app journey in Open Banking Gateway involves Salt Edge Connect widget, a set of interfaces where end-users choose their desired bank from which they want to share account information or initiate a payment toward a third party, and via which they grant consent for the corresponding action.
So, let’s figure out what we have to deal with.
Spoiler: No silver bullet!
Goal: seamless app2app redirection
Three actors are participating in the app2app redirect flow:
- TPP’s mobile application;
- Salt Edge Connect widget – web application;
- Bank’s mobile application.
The sharing of account information journey (AIS) includes several redirections between the parties. The end-user runs a TPP’s mobile application on iOS or Android, where the flow is initiated. TPP’s mobile application opens Salt Edge Connect widget, end-user searches for the desired bank and grants explicit consent for access to account information. After this short journey, the widget redirects the end-user to the bank’s mobile application for authentication.
After successful authentication, the bank’s mobile application redirects the end-user to Salt Edge Connect widget where the user can monitor the progress of data being fetched from the payment account, and finally, the user is successfully redirected to TPP’s mobile application.
Diagram 1. Redirection steps in app2app and app2web flow
Looks quite simple, right?
In spite of this, the developers of TPP’s and bank’s mobile applications face redirection issues on steps 2 and 4. For example, from the TPP app, users may be redirected to the bank website instead of the bank’s mobile application, resulting in a poor user experience.
Let’s review in more detail the technology that makes the redirections possible.
Technology: Deep links
Deep links are URLs that take users directly into specific functionality on a specific screen in an app.
There are two types of deep links:
- Links with HTTP scheme, similar to base web URL. These are called Universal links in iOS (iOS 9 or greater), or App links in Android (Android 6 or greater);
- Links with custom URL scheme instead of HTTP (e.g. appname://domain.name/action). These appeal directly to the application.
Universal links and App links are fully compatible with all platforms. Instead of opening the link in the browser app, the operating system will initially check if the corresponding app is installed and will open it. However, if some other apps that are installed on a user’s device can handle the same URL, the user might be taken to the incorrect app. This may cause unwanted redirection and a broken flow.
The operating system (iOS/Android) allows an app to designate itself as the default handler of a given type of link. If the end-user doesn’t want the app to be the default handler, it is possible to override this behavior from the device’s system settings.
To simplify the user experience, developers should create a two-way association between the app and the website, and specify the URLs that are handled by the app. This association will prove ownership of the host, so no other app can use these links.
Links with custom schemes are only compatible with mobile operating systems, which might be considered a disadvantage. On the other hand, they uniquely identify the application in the system and eliminate doubts about where to redirect, as well as they are easy to implement.
Solution: the right link in the right place
Salt Edge suggests to use:
- Universal links on step 2 (see Diagram 1), where the user is redirected from Salt Edge Connect widget to the bank’s app. Bank always owns the website to which user is redirected as an alternative to the missing bank’s mobile app on user’s device;
- Links with custom URL schemes on step 4 (see Diagram 1), where the user is redirected from Salt Edge Connect widget to the TPP’s mobile app.
Here’s a short to-do list.
For the bank’s mobile application, developers should setup:
Additionally, it is required for banks to host association files on the application website for app2app redirect to be handled correctly:
- “https://domain.name/apple-app-site-association” for iOS; and
- “https://domain.name/.well-known/assetlinks.json” for Android.
For TPP’s mobile application, developers should setup:
As it was mentioned above, there is “no silver bullet”, because developers of one app can’t control other actors and their environments. The above-mentioned issues can appear when specific browsers (e.g. Xiaomi browser) do not want to either redirect to an application when the operating system ignores the “default application” setting, or when developers of a bank’s mobile app have set up associations for iOS application, but not for Android application.
Communication between mobile applications can be easy when all participants follow the rules of the mobile operating system. When the conditions described above are met, end-users experience smooth linking of their accounts or initiating payment via the TPP’s mobile application.
To offer you tips on how to further polish the app2app redirect experience in Android or iOS, check out the following articles:
See App2app redirection consistency in Android article
See App2app redirection consistency in iOS article
Written by Constantin Chelban, Lead Mobile Developer at Salt Edge
About Salt Edge
Salt Edge – a financial API platform with PSD2 and open banking solutions. The company has two main vectors of activity: enabling third parties to get access to bank channels via a unified gateway, and developing the technology necessary for banks to become compliant with the directive’s requirements. ISO 27001 certified and AISP licensed under PSD2, the company employs the highest international security measures to ensure stable and reliable connections between financial institutions and their customers. The company is integrated with 5000+ financial institutions in 50+ countries.
Salt Edge report
Discover what is the current state of open banking payments in Europe in 2021