Frisbii Checkout can be integrated into a native mobile app by using WebView approach.

📘

NOTE

Deep Linking is required when using payment methods that can perform app switch such as MobilePay or Vipps. See here how to set up app scheme URL

Requirements

• Deep linking setup ( iOS URL Scheme or Android Deep Links ).

• A native WebView ( iOS WKWebView or Android WebView ).

• Set your app scheme URL as an alternative return URL on Checkout session creation.

  • NOTE: alternative_return_url is placed under session_data object.
  • Example: alternative_return_url: "MyCustomApp://?".

• Receive events from Frisbii Checkout using Native Bridge channels.

• Handle incoming URL once returned back from a Mobile Payment App e.g. MobilePay ( iOS handle incoming URL or Android handle incoming URL ).

  • NOTE: The incoming URL consists of your app scheme URL and query parameter returnUrl. E.g. MyCustomApp://?returnUrl=https://checkout.reepay.com/... .
  • Once Frisbii Checkout return URL has been loaded in WebView, the checkout will either send an event of the payment outcome (e.g. Accept Event), or redirect to your Accept URL / Cancel URL if exists.

• Handle Frisbii Checkout events in WebView

  • The WebView must handle the incoming event messages from Frisbii Checkout via Native Bridge channels. Examples for iOS and Android WebViews can be found here.

Redirect to App

For payment methods that has Mobile App such as Vipps/MobilePay/Swish, Frisbii Checkout redirects to their app scheme URL (e.g. Vipps' app is vipps://...), once detected as a mobile device.

Otherwise, it will redirect to the payment method's original website (e.g. Vipps MobilePay's website https://vippsmobilepay.com/...).

Redirect options

If you prefer to use web-based redirect instead of app switch on Mobile Device, please refer to Vipps desktop flow flag or Swish desktop flow flag.

• This would allow e.g. Vipps MobilePay's website handling the app switch to their mobile app.

If you want to force use mobile flow at all times, you can create a session with force_mobile parameter.

• This would force the app switch directly from Frisbii Checkout by attempting to open an app scheme URL.
  Note that this would neither redirect or perform app switch, if the mobile app is not installed on the user's phone.

Return from App

Upon return from a Mobile Payment App such as MobilePay app, it will by default return to Frisbii Checkout website (https://checkout.reepay.com/...). This will result in opening of a browser app on the mobile such as Chrome or Safari app.

To return to your own app, it is required to have created a Checkout Session with alternative_returl_url that includes your app scheme URL such as:

{ 
  ...
  "session_data": {  
    "alternative_return_url": "MyCustomApp://?"  
  }
  ...
}

The Mobile Payment App (e.g. MobilePay app), will return an URL that must be handled in your app. The returned URL will be MyCustomApp://?returnUrl=https://checkout.reepay.com/....

In your app, you need to extract the returnUrl and load it in your WebView. You can find how to handle incoming URL on the following pages for iOS and Android .

📘

NOTE

Examples of how to handle incoming URLs can be found on our iOS demo app and Android demo app

Handle events

📘

NOTE

Native Bridge has been introduced in January 2025. It will no longer be required to use accept and cancel URLs to handle events. Read more here.

Handling of events relies on URL changes. Your WebView must register a listener on URL changes. When creating a Checkout Session, it is required to add accept_url and cancel_url.

It is recommended to add additional query parameters to your URLs to contain relevant information that can be used after payment fails or completes. They be extracted once WebView has detected that the Checkout has redirected to Accept/Cancel URL.

{ 
  ...
  "accept_url": "https://mywebsite.com/accept?id=xxx", 
  "cancel_url": "https://mywebsite.com/cancel?id=xxx",
  ...
}

Further development

It is generally recommended that your app handles other events, such as when a user closes WebView/Checkout, creation of unique Checkout Sessions, and a final screen after a payment has been cancelled or paid successfully.

This will provide the user the best user experience and a seamless mobile app payment experience.