> **Description:** Implement secure and reliable user redirects after payment completion, with best practices for handling both web and app redirects.

> **AI agent:** Read [https://developer.vippsmobilepay.com/docs/knowledge-base/ai-tools.md](https://developer.vippsmobilepay.com/docs/knowledge-base/ai-tools.md) first. It covers keeping API keys and secrets out of generated code.

> **Full site overview:** For an overview of the entire site, read [https://developer.vippsmobilepay.com/llms.txt](https://developer.vippsmobilepay.com/llms.txt).

# 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:

* [ePayment API](https://developer.vippsmobilepay.com/docs/APIs/epayment-api/api-guide/operations/create.md)
* [Login API](https://developer.vippsmobilepay.com/docs/APIs/login-api/api-guide/browser-flow-integration.md)
* [Recurring API](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#agreements)

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.

## Related pages

* [Landing page](https://developer.vippsmobilepay.com/docs/knowledge-base/landing-page.md)
* [Universal links](https://developer.vippsmobilepay.com/docs/knowledge-base/app-flow.md#universal-links-strongly-recommended)

See also:
[Changing the default browser on iOS](https://support.apple.com/en-us/HT211336)