Our WebUI is a responsive web application suitable for both mobile and desktop. The WebUI URL is fetched from the APIs and displayed to the user.

The WebUI can be implemented in different ways depending on your requirements and tech stack:

WebView
Overlay browser
Browser tab
IFrame

WebView

The most common choice of implementing the Minna UI is through a WebView. The WebView acts as the container for our features and is launched on top of the native bank application. To implement the WebView we refer to the official documentation for your platform.

Android
IOS

More information on webview requirements

Browser requirements
The webview should have JavaScript enabled, since the WebUI is built with JavaScript. The webview should also be of a fixed size and not dependent on the size of its contents.

Lifecycle
When a user navigates into our domain, the webview URL will change. The webview needs to keep track of the currently active URL at all times, so that it can reload when needed. This is due to the fact that the native application can be temporarily closed down by the operating system when a third-party application opens (for example an app for e-signing or email client), or when a user triggers screen rotation. The currently active URL and the page content should then remain the same when the webview is re-initialised.

Android back button
The default behavior in Android when pressing the back button is to pop from its own backstack. As the customer navigates around in the webview, the URL will be continuously updated. The expected behavior from the user is that the back button should navigate the user back within the webview. Therefore, any back button clicks should be delegated to the webview.

Opening WebUI URLs

This section describes how to display a WebUI URL to the user. It is assumed that you already fetched the WebUI from the API.

{
    "webUi":{
    "url":"https://example.minna.tech/overview?locale=en-GB"
      "authToken":"aQcDW2I09YTbc"
      "validTo":"2019-08-02T23:59:59+01:00"
    }
}

It is not enough to display the URL to the client, you also need to include the authToken. There are two ways of displaying the URL, through POSTor GETrequests.
The authToken is only valid once.

POST request

You can make a POST request from the users client to the URL given in the previous step.

The authToken from the previous step should then be URL-encoded and included in the request body, for example as authToken=mK9cFiqpaLIiesDhDPgfA7b9wqP6O6WxkQpcGo67. The Content-Type should be application/x-www-form-urlencoded.

For more instructions on how to submit POST requests into Webviews, see the official documentation:

Android: Webview.postUrl
iOS: Webview.loadRequest

GET request

You can make a GET request from the users client to the URL given in the previous step.

The authToken from the previous step should then be URL-encoded and included as the query parameter authToken. For example:

https://sandbox.minna.tech/api/v1/user-session/login?locale=en-GB&redirectTo=/subscription/82b4c9bd-c930-4f27-b843-ff1064d5c2f4/details&authToken=mK9cFiqpaLIiesDhDPgfA7b9wqP6O6WxkQpcGo67

(Note that the URL might already have query parameters)

🚧
The GET approach is less secure, and should only be used in development.
The authToken is sensitive information, as it grants the holder instant access to the application. When the authToken is part of the URL, it could be logged by intermediary systems and therefore be exposed to third parties. Therefore, it is better to use POST request for production implementations

Communication

There are a number of use cases where we needs to communicate with the native bank application in order to provide a smooth user experience and function properly.

We recommend that a global JavaScript object called nativeHost should be exposed in the webview. we will call methods on this object to communicate with the native bank app. The following functions should be exposed on the global window object:

Android: window.nativeHost.call

iOS: window.webkit.messageHandlers.nativeHost.postMessage

The WebUI will in turn expose a global JavaScript function called onWebviewHostMessage(<String>) which allows the native host to post messages to us. This is mainly used for error reporting.

Messages

The following messages can be sent by us and should be handled by the native application:

Description	iOS	Android	Callback
Starts the application used for e-signatures	webkit.messageHandlers.nativeHost.postMessage(‘{ “action”: “OPEN_E_SIGN”}’);	nativeHost.call( ‘OPEN_E_SIGN’)	“noESignAppFoundError”
Close the webview	webkit.messageHandlers.nativeHost.postMessage(‘{ “action”: “CLOSE_WEB_VIEW” }’);	nativeHost.call( ‘CLOSE_WEB_VIEW’);	No callback
Open external link*	webkit.messageHandlers.nativeHost.postMessage(‘{ “action”: “OPEN_LINK”, “url”:”https://www.weburl.com” }’);	nativeHost.call( ‘OPEN_LINK’, ‘{ “url”: ”https://www.weburl.com” }’);	No callback
Native app session keep-alive **	webkit.messageHandlers.nativeHost.postMessage(‘{ “action”: “PING” }’);	nativeHost.call( ‘PING’);	No callback

Table explanations

*: Open external links: The use cases include:

Open the email client through mailTo links, for example to send an email to our customer support
Open supplier web page to view contract terms
Open web page to perform download of GDPR extract
If the service provider doesn't approve cancellations through letter of attorneys, the user can open the cancellation page with that supplier (for example: www.netflix.com/cancelplan)

**: Native app session keep-alive: This function is called periodically when the user is active, so that the native app session won't time out and log out the user. This is called when the user performs actions, for example navigating from one page to another, within the WebUI and with a minimum interval, e.g. only once per minute.

Theming

The WebUI can be customized according to your theming and colors. The following aspects can be customised:

Colors
Fonts
Shadows and border-radiuses
Images

To customize the appearance of your WebUI, contact Minna.