MobilePay Online checklist

To ensure that your system is ready for production, you must have performed the basic API calls as described below. Once we have verified that the steps have been completed successfully, you are ready to start testing in hidden production.

When your test in hidden production is done, we will verify this, and you'll be able to go live and offer MobilePay Online to your clients.

Mandatory implementations

Please note that the following is mandatory implementation, and you will not be able to go live without these. If we determine that you don't utilize the mandatory implementation in production, we will reach out to you in order to resolve the situation and ensure the mandatory implementations. The reason for the mandatory implementation is to ensure the best user and merchant experience and satisfactory conversion rate.

• SCA implementations: That includes delegated authentication for Visa, Mastercard, and Dankort; as well as 3DS fallback. See SCA for details.
• Onboard individual merchants and not super merchants. See Merchant onboarding for more details.
• Make sure all merchants have an MCC registered.
• Use merchant/webshop name and logo when initiating payments. See below section on Merchant onboarding for more details.
• Ensure merchants use correct and updated MobilePay logo and buttons. Visit our Design page for guides and resources.
• Update all payments with capture or cancel and if refund is performed.

Onboard production merchants and initiating payments

In order to onboard merchants, you must use: POST:/api/v1/merchants. It's only possible to onboard merchants using the API. *When onboarding merchants, it is important that you onboard each individual merchant/webshop and no super merchants. Please visit the API documentation to see which input is needed to create a merchant.

The input giving when creating merchants is only used for billing and support purposes. The information shown to the users when completing payments is supplied when initiating payments using POST:/api/v3/payments. Similar to merchant creation, it's important that you use the details of the specific merchant and not a super merchant or payment facilitator.

Therefore, you must use the proper merchant/webshop name as well as logo. This will ensure better user experience and conversion rate.

Contact us at developer@vippsmobilepay.com if you have any questions or concerns regarding merchant onboarding.

Verification in test

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

Please email developer@vippsmobilepay.com with data for each point or use this template.

Merchant

1. Create merchant: POST:/api/v1/merchants - externalId
2. Delete merchant: DELETE /api/v1/merchants/{merchantId} - merchantId

Payment

3. Initiate payment: POST:/api/v1/payments - pspReferenceId
4. Update authorization attempt with succeeded:true: PATCH:/payments/{paymentId}/authorizationattempts/{authorizationAttemptId} - paymentId
5. Update authorization attempt with succeeded":false: PATCH:/payments/{paymentId}/authorizationattempts/{authorizationAttemptId} - paymentId
6. Create capture: POST:/api/v1/payments/{paymentId}/captures - paymentId
7. Create cancel: POST:/api/v1/payments/{paymentId}/cancels - paymentId
8. Create refund: POST:/api/v1/payments/{paymentId}/refunds - paymentId

App switch

9. If you offer your merchants to use apps, you must test a switch between MobilePay app and a merchant app.

Callbacks

10. Received token callback - paymentId
11. Received failed payment callback (not required) - paymentId

SCA implementation

12. Implemented delegated authentication for Dankort. If you have not implemented this please explain why.
13. Test 3DS flow with "succeeded":false "reasonCode":1008: PATCH:/payments/{paymentId}/authorizationattempts/{authorizationAttemptId} - paymentId

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.

PLEASE NOTE

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.

Design guidelines

We want to make it easy for you to ensure that the right MobilePay buttons and logos are used by the merchants. 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.

tip

Operational issues are supplied through our operational status pages. Sign up for the updates through the new pages.