MobilePay Online checklist

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 below actions. All actions are mandatory unless explicitly stated otherwise.

Send your filled out MobilePay Online Test verification checklist to us at developer@vippsmobilepay.com.
Use this editable 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 - 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

Mandatory implementations

Appswitch 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 valid MCC. See merchant onboarding for more details. All merchants must use their own merchant/webshop name and logo when initiating payments.

Payment status All payments must be updated with capture or cancel status, as well as refund if this is performed.

Design guidelines Proper use of our logo and buttons will ensure better user experience and conversion rate. Please visit our Design page for more information and resources.

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 authorisationAttempt 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

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

• Merchant registration: How to set up MobilePay Online including as 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. Sign up for the updates through the new pages.