App-to-App Redirection: an overview
As defined by OBIEOpen Banking Implementation Entity – organization created by the CMA (Competition and Markets Authority) to deiver APIs, data structures and security architectures that enable developers to harness technology, making it easy and safe for account holder's to share their financial information held by the banks with third parties. / PSD2PSD2 stands for Payment Services Directive 2 and is a new EU regulation in effect since September 14, 2019. It governs electronic and other non-cash payments. The main provision of PSD2 is for Strong Customer Authentication (SCA), a process that seeks to make online payments more secure and reduce fraud while increasing authorisation rates. The European Banking Authority (EBA) recently extended the deadline for PSD2 compliance until December 31, 2020., an app-to-app redirect allows the TPPThird-Party Provider – an authorised online service provider introduced as part of Open Banking. TPPs exist outside of the account holder’s relationship with their bank but may be involved in transactions carried out by the user. to redirect a PSUPayment Services User – an individual person or legal business entity making use of an Open Banking service as a payee, payer or both. from the TPP application (in a mobile web browser or mobile app) to the bank's (ASPSPAccount Servicing Payment Services Provider – any financial institution that offers a payment account with online access. This includes banks and building societies. PSD2 requires ASPSPs to provide access to trusted third parties for initiating payments and accessing account information.) 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'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 (URIA Uniform Resource Identifier (URI) is a string of characters that unambiguously identifies a particular resource. To guarantee uniformity, all URIs follow a predefined set of syntax rules, but also maintain extensibility through a separately defined hierarchical naming scheme (e.g. http://).) 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 (hover 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:
- There must be a functional mobile website to fall back to gracefully if the target app is not installed
- There are no built-in deferred deep linking capabilities.
Let's now take a deeper look at the user checkout experience enabled by Token's App-to-App Redirect feature.