App-to-App Redirection: an overview

As defined by OBIE/PSD2 , an app-to-app redirect allows the TPP to redirect a PSU from the TPP application (in a mobile web browser or mobile app) to the bank's (ASPSP) mobile app, when the latter is installed on the PSU's device. The TPP transmits details of the request (account information or payment) along with the PSU's preferences (e.g., product type, one-step authentication) through the respective Universal Link (iOS) or App Link (Android) and redirects the PSU to the bank app's login screen or function. The PSU then provides consent and is authenticated by the banking app using the same credentials/methods normally used when the PSU directly accesses the account using the bank app (typically, biometric).

Prior to the introduction of Token.io's App-to-App Redirect feature, the redirect flow for PSU consent involved redirecting the user to the bank's website opened in the default mobile browser on the device. Upon bank validation of PSU consent, the user was then redirected back to the TPP mobile app to continue request processing. However, this method is neither seamless nor friction-free and is likely to result in a poor user experience.

Hence, rather than an exclusive app-to-web redirect, the preferred app-to-app redirect experience, when the bank app is present on the device, lets the PSU access the bank's mobile app from within the TPP's mobile app to provide consent. The user is then seamlessly returned to the TPP mobile app to continue.

Universal/App Links vs. Deep Links

Deep links are a precise way to connect a user to a specific location in another app. On a web site, whether you use Safari or another browser like Chrome, most of the links you click are deep links. For example, a link to a hot news story on CNN takes you directly to a page with the story, not to the home page of CNN.

In mobile, deep linking has historically been more difficult. One reason is because apps don’t use a standardized link format like HTTP or HTTPS. That's because mobile apps need a uniform resource identifier (URI) to enable deep linking. With the web, there is one standard format for links, whereas with mobile the format varies by operating system (e.g., Android, iOS, Windows, etc.).

By contrast, Universal/App Links tell the web browser what to do if the app to which you want to link is not installed. With Universal Links, a hyperlink redirects the mobile device user to either content on a mobile website or to similar content in a mobile app, depending on whether or not the app is installed. The link itself points the web browser to a link map/URL scheme/app link scheme on a secure website that defines where users are redirected based on their install state.

As depicted in the flow chart below (click to enlarge), when a Universal/App Link attempts to open for the user, the mobile OS determines if the content should be shown in the mobile app or mobile website.

The respective policy governing Universal/App Links varies between iOS and Android. In general, iOS imposes strict security protocols on universal linking, whereas Android policy is somewhat less stringent. The biggest difference, however, lies in the iOS requirement that universal links are only invoked by a legitimate (true-touch) user tap. Attempts to simulate or emulate a real user tap with automation are blocked.

Universal Link Handling by iOS

Before Universal Links, the primary mechanism to open up an app when it was installed was redirecting to the app’s URI scheme in Safari. This put the routing logic in the browser, but there was no way to check if the app was installed or not. This meant that developers would try to call the URI scheme 100% of the time, on the off chance that the app was actually installed, then fallback gracefully to the App Store when not using a timer.

Universal Links largely fix this. Instead of opening up Safari first when a link is clicked, iOS will check to determine whether a universal link has been registered for the domain associated with the link, then check if the corresponding app is installed. If the app is currently installed, it will be opened. If it’s not installed, Safari will open and the http(s):// link will load.

Android App Link Handling

As discussed above, App Links are Google’s response to Apple’s introduction of universal links. Supported by Android Marshmallow (6.0) and later versions, they are HTTP URLs that can be used to link to content inside a native app if it is installed on the device.

For example, let's say you have the URL https://example_bank.com/login and the same content/sign-in functionality is also available on your native app. If the user clicks the link on an Android device and App Links are properly configured, the link will open the appropriate content on the native app, if it’s installed, but would otherwise open the URL in the browser.

In almost all respects, App Links on Android are essentially identical to Universal Links on iOS. Moreover, both have the same two major limitations:

1. There must be a functional mobile website to fall back to gracefully if the target app is not installed
2. There are no built-in deferred deep linking capabilities.

Let's now take a deeper look at the user checkout experience enabled by Token.io's App-to-App Redirect feature.