Skip to main content
View as Markdown (opens in a new tab)

Return URLs and redirects

After users complete an action in the Vipps or MobilePay app—such as completing a payment, logging in, or accepting an agreement—you can redirect them to your website or app.

The following APIs provide redirect functionality:

When the API request is complete, it will return a URL.

The phone's operating system uses universal linking to recognize that the URL is owned by Vipps MobilePay. This triggers an app-switch, automatically opening the Vipps or MobilePay app for seamless payment confirmation — without user input.

Example flow​

An example of how redirects are handled:

  1. The user starts a web session in the non-default browser (e.g., Firefox).
  2. A Vipps MobilePay purchase is started where the merchant specifies a redirect URL.
  3. The user completes the purchase in the Vipps MobilePay app.
  4. The app requests the operating system to open the URL specified by the merchant.
  5. The OS opens the URL in the default browser, not necessarily the browser where the session started (e.g., Firefox).
  6. The merchant handles the redirect without the customer noticing any discrepancies from the browser switch.

Best practices​

We have limited control over the redirect back to the merchant's website after a completed purchase or log-in. Your integration must not assume that the app will redirect to the exact same session. For example, don't rely entirely on cookies in order to handle the redirect event. The redirect may send the user to a different web browser.

Examples of some, but not all, factors outside our control:

  • Configurations set by the operating system, for example the default browser.
  • User configurations of browsers.
  • Users closing the app immediately upon purchase.

Because of this, we recommend a stateless approach on the website that should be the end of the session. For example, implement polling-based result handling from a value in the redirect URL.

Repeated visits to the return URL​

Return URLs must not trigger side effects

The URL that returns the customer to your website after a payment or an agreement may be opened more than once, including simultaneously. For example, the payment widget's iframe and the parent page may both open it.

Treat this URL as a page for displaying the result. Opening it must not trigger order updates or other side effects, such as sending confirmation emails or starting fulfillment. A visit to the return URL is not proof of a successful payment.

Confirm the payment status on your backend by polling the API. Handle order updates and other side effects on your backend, independently of visits to the return URL. Make this processing idempotent and safe for concurrent requests so that each update and its side effects happen only once, even when multiple requests arrive simultaneously.

Troubleshooting​

Timeout​

The app-switch only works if the landing page URL opens within ~3 seconds after the user clicks the link. Delays longer than that may prevent the switch, and result in the landing page being shown. This is based on observed behavior, as the exact timeout isn't documented by Apple or Google.

Ad blocker​

If the user has installed an ad blocker, that may cause problems opening a URL with custom URL schemas.

Custom and embedded browsers​

If the payment started in a custom browser (like Chrome on iOS, or an embedded browser on Instagram, instead of the default Safari browser), the redirect URL (the result page) will still be opened in the default browser.

See also: Changing the default browser on iOS

Last updated on