This section offers instructions on how to implement MobilePay as a payment method in your merchant app.

When implementing, it is important that you understand how the payment flow works and are aware of how to handle possible errors that may occur during the flow. Reading and following our guidelines enables you to give your users the best possible experience with a hassle-free payment flow.

In the sections below you can read and learn more about the AppSwitch SDK and AppSwitch API, including how to get started with the implementation. Example code is also available on GitHub.

Before you get started, it is necessary to have a MobilePay AppSwitch Agreement. If you haven’t already, you can sign up here.

When you have a MobilePay AppSwitch Agreement and a Merchant ID, you must onboard our REST api by following the steps here.

MobilePay AppSwitch SDK

The AppSwitch SDK makes it easy to receive payments from MobilePay in your app.

We offer AppSwitch for iOS and Android.

The SDK is updated continually to improve the solution. Please find more information about new SDK releases and an overview of known errors here:

For more information regarding support of SDK versions, please refer to the licence terms.

See the implementation guide for AppSwitch and a guide on how to get started on your desired platform. The guides will show you how to enable AppSwitch, add the SDK to your project, create your first payment and handle callbacks from MobilePay.

You can also see a sample app showcasing the use of AppSwitch SDK on your desired platform.

MobilePay AppSwitch API

To use the AppSwitch API, a number of steps must be completed. The following links provides documentation on how to get onboarded as a user and start sending request to the AppSwitch API.

The AppSwitch endpoints are provided for communication between the merchant backend and the MobilePay backend.

A valid AppSwitch merchant ID is required for calling the endpoints (sandbox environment is currently not available).

When you call an endpoint, you will get a response that includes a status code along with detailed information of the transaction.

It is recommended that you test the AppSwitch API thoroughly to ensure that all possible error scenarios are handled properly.

Payment flow
  1. When MobilePay is selected as a payment option in the merchant app, the user is taken to the MobilePay app where the payment amount will be presented.
  2. The user can either swipe to complete the reservation or interrupt the payment flow, for example by closing down MobilePay or going to the phones home screen.
  3. The Payment Status endpoint can be called to ensure that the reservation has been made. If everything is okay, the data flow can continue. Otherwise, a re-try is recommended.
  4. The amount is withdrawn by calling the Capture Amount endpoint.
  5. In case a reservation is made, but the order somehow must be cancelled, the reservation can be deleted by calling the Cancel Reservation endpoint.
  6. Amounts can be refunded, either fully or partially, by calling the Refund Amount endpoint.

In order to ensure a good user experience when using MobilePay AppSwitch, we recommend you to test the payment flow thoroughly and handle possible errors that may occur.

AppSwitch payments can be trickly to handle, especially cases where user interrupts the payment flow. Feel free to contact us at for further guidance.

Error handling

A proper error handling of AppSwitch payments is extremely important since communication between MobilePay and merchant app can be interrupted. In case a response from the MobilePay SDK is not received within reasonable time (e.g. 20 seconds), the Payment Status endpoint should be called.

500 Internal error
There is also a small chance that calling Capture will return a 500 (internal server error) error response. This doesn't necessarily mean that the Capture didn't go through. Either call Payment Status to get the status of the current payment, or try capture again. If already captured, it will respond with code 409 (Transaction already captured).

Capture errors and reservation expiry
Be aware that reservations do expire after a minimum of 7 days. This means that capturing succesfully in time is important if merchants are not to lose money. If capture attempts fail and you are unable to solve the underlying issue make sure you contact as soon as possible so the issue can be solved before reservations expire.

Order Polling (PaymentStatus)
We recommend that you implement server side polling (Calling PaymentStatus) to minimize your reliance on the App Switch itself being successful. In general, it is a big weakness to be too reliant on the App Switch itself. By polling the PaymentStatus, the merchant back end will always know whether a reservation has been made or not.

Design guidelines

We want to make it easy for you to ensure that the right MobilePay buttons and logo's are used by the merchants.

Please visit our Design page for more information and ressources. 

We recommend the labels 'Betal med MobilePay' or as a minumum 'MobilePay'. From user testing we have learned that 'Betal med MobilePay' converts best. 

MobilePay Logo