> **Description:** A comprehensive implementation checklist for MobilePay Online PSP integration, ensuring all required features, security measures, and testing scenarios are properly completed before going live.

> **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).

# MobilePay Online checklist

**Maintenance mode**

This API is in maintenance mode: we continue to support and maintain it, and no end of life date is planned.
New PSP functionality is added to the [ePayment API](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/README.md), so we recommend it for
new integrations.

This API is only available in the Danish and Finnish markets.

To ensure that your system is ready for production, we must verify your solution in test and production. Once we have verified that the steps have been completed successfully, you are ready to go live.

## Verification in test

Before moving to hidden production, you must have performed the following actions. All actions are mandatory unless explicitly stated otherwise.

Send your filled out MobilePay Online Test verification checklist to us at [developer@vippsmobilepay.com](mailto:developer@vippsmobilepay.com).
Use this [editable PDF](https://developer.vippsmobilepay.com/downloads/mobilepay-psp-api/mpo-checklist.pdf) to fill out and submit. Request examples in the checklist must be no more than 1 month old when you submit the checklist.

**Download the editable MobilePay Online Test verification checklist**

**[Download the PDF](https://developer.vippsmobilepay.com/downloads/mobilepay-psp-api/mpo-checklist.pdf)** -- an editable PDF you can fill out and track your progress.

---

## MobilePay Online test verification checklist

### Endpoints to integrate

It is important that you integrate *all* the API endpoints.

#### Merchant

| Purpose | Endpoint |
| --- | --- |
| Create merchant | POST /api/v1/merchants |
| Delete merchant | DELETE /api/v1/merchants{'{merchantId}'} |

#### Payment

| Purpose | Endpoint |
| --- | --- |
| Initiate payment | POST /api/v1/payments |
| Update authorization attempt with succeeded:true | PATCH /payments/{'{paymentId}'}/authorizationattempts/{'{authorizationAttemptId}'} |
| Update authorization attempt with succeeded:false | PATCH /payments/{'{paymentId}'}/authorizationattempts/{'{authorizationAttemptId}'} |
| Create capture | POST /api/v1/payments/{'{paymentId}'}/captures |
| Create cancel | POST /api/v1/payments/{'{paymentId}'}/cancels |
| Create refund | POST /api/v1/payments/{'{paymentId}'}/refunds |

#### Other topics

| Topic | Task |
| --- | --- |
| Callbacks | Received token callback |
| Callbacks | Received failed payment callback (not required) |
| SCA implementation | Delegated authentication for Dankort (if not supported leave blank) |
| SCA implementation | Test 3DS flow with succeeded":false "reasonCode":1008 |

### Branding

| **Branding compliance and checkout visibility** Following the [terms and conditions for Vipps MobilePay Business Solutions](https://vippsmobilepay.com/en-NO/terms-and-conditions): * Make Vipps MobilePay just as visible and easy to access as other payment methods, including digital wallets and payment apps. * Make Vipps MobilePay directly accessible, with no secondary menus or extra steps. * Show Vipps MobilePay at the same level as comparable payment methods. * Avoid consistently giving Vipps MobilePay a lower priority in the display or checkout flow. * Present Vipps MobilePay in a way that keeps checkout fair, easy to understand and quick to use. [See logos, text, and dos and don'ts for the checkout](https://brand.vippsmobilepay.com/document/61#/branding/online/branding-in-the-checkout) |
| --- |
| #### Use the approved buttons Show only the approved Vipps MobilePay buttons. **Recommended:** Use the buttons from the [button generator](https://developer.vippsmobilepay.com/docs/knowledge-base/buttons.md). The generated buttons work with keyboard navigation and screen readers, and they stay up to date with the brand. |

### Mandatory implementations

| Support soft decline step-ups In case of a soft decline (when the issuer requires 3DS), the PSP must host a 3DSecure session and must provide the URL to Vipps. See [Strong Customer Authentication (SCA)](https://developer.vippsmobilepay.com/docs/APIs/psp-mp-api/mp-psp-api-guide.md#strong-customer-authentication). |
| --- |
| Do not rely on `redirectFromMobilePayUrl` Some users may close the MobilePay app immediately after seeing the payment confirmation, therefore not being "redirected" back to the merchant. Because of this, it is important for the merchant and the PSP to not base their transaction logic on the user reaching the ` redirectFromMobilePayUrl `. |
| App Switch If you offer your merchants to use apps, you must test a switch between MobilePay app and a merchant app. |
| Merchant onboarding All merchants must be onboarded as individual merchants and not super merchants, and they must be onboarded with a valid MCC. See [merchant onboarding](https://developer.vippsmobilepay.com/docs/APIs/psp-mp-api/mp-psp-api-guide.md#onboarding) for more details. All merchants must use their own merchant/webshop name and logo when [initiating payments](https://developer.vippsmobilepay.com/docs/APIs/psp-mp-api/mp-psp-api-guide.md#payments). |
| Payment status All payments must be updated with capture or cancel status, as well as refund if this is performed. |

We will verify the above requests and move you to production.
If you have not yet supplied us with a publicKey for production, please send it in a ZIP-file.

**Important**

Registration of publicKey in production takes longer than in test. So please provide us with the production key well in advance.

## Go live

### Slim certification

Before you can offer your MobilePay Online solution for your clients, we will perform a 'slim certification'
and you must supply merchant documentation. The 'slim certification' is performed in production and is required before you can go live.

#### Slim certification - test webshop

In order to complete the slim certification, you must supply a test webshop in production.
The test web shop should contain items for around 1 DKK for which we can test various flows. We will test the following:

1. Dual device and single device:
    * Happy day
    * Payment expire
    * User reject
2. Let request expire and see successful `failedPaymentCallback` (only if `failedPaymentCallback` is used)
3. Perform multiple authorization attempts for the same payment
4. Accept payment with a non-working card (e.g. no funds) and check that a PATCH
   on `authorizationAttempt` is made with `succeed: false` with a meaningful `responseCode`.
5. We will ask you to capture and afterwards refund one of the test payments
   (the rest of the payments should be cancelled or expire)
6. Confirm implementation of 3DS, VTS, and Dankort SCA implementation
7. Go through [merchant documentation](#merchant-documentation).

### Merchant documentation

The documentation towards your customers, the merchants, must cover the following, at a minimum:

* Merchant registration: How to set up MobilePay Online, including as a minimum, information about:
  * Name displayed in the app to the end user
  * `LogoUrl` linking to an image file displaying the merchant logo in the app to the end user
    * 250x250 pixels
    * Hosted using a secure HTTPS connection
    * PNG or JPG
    * Set content-type in the HTTP header using *MIME* types, e.g. *image/png* or *image/jpeg*
* App switch feature: How the solution is used from a native app (API enabled)
* Common pitfalls of 'context switch' on client side
  * Scenario A: *browser A -> MP App -> browser B*.
    The Merchant return page should not rely on any sort of session object (e.g. a cookie)
    to recognize the returning customer. It should solely rely on data given in the redirect (`redirectFromMobilePayUrl`).
  * Scenario B: *browser -> MP App*.
    The Merchant should not rely on the customer returning client side.
    Rather, they should process the purchase when the PSP's server-to-server callback is received,
    or after getting confirmation on a status endpoint.

### Operational updates

Operational issues are supplied through our [*operational status pages*](https://developer.vippsmobilepay.com/docs/knowledge-base/status-pages.md).
Sign up for the updates through the new pages.