Getting started

In order to implement MobilePay Online, you must first obtain an agreement by submitting the PSP partner form Once the agreement is signed, you will get access to our test environment and can test the API.

Test

note

MobilePay Online does not use the same security solution as the remaining Vipps MobilePay APIs. If you already have test credentials or partner keys these cannot be used for MobilePay Online. You must request new credentials.

• Credentials: During onboarding, you will receive a client ID and client secret for test, as well as a test user. If needed, you can request a new by contacting developer@vippsmobilepay.com. Please state if you need a Danish or Finnish user.
• Endpoints: The test endpoints can be found in the API specification.
• Test app: Download and login instructions for the test app can be found on the test apps page.

Note: It's not possible to add your own cards to the test users. Instead, you can use magic numbers.

PublicKey

You must supply two PublicKeys for Card encryption: The RSA public key should be provided as X.509 SubjectPublicKeyInfo (using ASN.1 DER Encoding) represented in PEM encoding (use PEM file extension). The public key must have a length of 4096 bits. You must clearly state in the file name which one is for Sandbox and which is for Production.

Naming template for public key: {integratorname}-{environment}-public

Example for sandbox: company-sandprod-public

Example for production: company-prod-public

Please send the PublicKeys in a ZIP-file. We will register the keys and supply you with a PublicKeyId to be used when initiating payments.

note

Please note that if a public key is unused for 6 months, we will delete it. If this happens you must supply a new public key.

Magic numbers for EMVCo Tokens

It is not possible to add payment cards in the test app. Any request to the PSP API will return a Visa Token. However, this can be changed by setting the amount in the init request.

No matter what is selected in the app, the token returned by the MakePayment request will be:

Amount Value (minor currency unit)	Token Number	Expiry	Cryptogram
2200	5226603115488031	05/25	AlhlvxmN2ZKuAAESNFZ4GoABFA==
3100	Emulates Card not eligible
3200	4111111111111111	03/30	uxToh3Ep6gsR8AAkvZALN19Iz34=
4200	4895370013193500	03/30	AlhlvxmN2ZKuAAESNFZ4GoABFA==
4300	5226603115488031	03/30	AlhlvxmN2ZKuAAESNFZ4GoABFA==
4400	4895370012792682	12/22	AgAAAAAAAIR8CQrXSohbQAAAAAA=
5100	4268270087302871	09/24	AgAAAAAAAIR8CQrXSohbQAAAAAA=
5200	5413330089010442	12/25	AgAAAAAAAIR8CQrXSohbQAAAAAA=
5300	4895370013193500	03/30	/wAAAAwAUkMTObMAAAAAgS0AAAA==
All other amounts	4895370013193500	05/25	AlhlvxmN2ZKuAAESNFZ4GoABFA==

For instance:

"amount": 3100, Will emulate a card that is not eligible.

PAN test card

"amount": 5400 will result in a card data callback with an encrypted VISA-DEBIT PAN.

"amount": 3100 which emulates Card not eligible will fallback to PAN and also result in a card data callback.

Test options for merchants

It is the responsibility of the PSP to offer test options to their merchants. It's not possible for merchants to perform test directly towards MobilePay.

There are two test options you can use:

1. Perform test using the test API. To do this, you must supply your merchants with the test user that we have supplied to you during technical onboarding. Your merchants can either use the test app or you can make the user simulation API available to them. It is your responsibility to instruct and support merchants in the use of our test app and user simulation API. We have made a 'Merchant Sandbox Testing' page with instructions about the test app. You can supply this to your merchants along with the phone number of your test user.

2. Perform test using the production API. In order to perform tests in production, you can either create a merchantId used only for test payments or merchants can test using their own merchantId. To do this, merchants must use the production MobilePay app downloaded through App store or Google Play and a production user. All payments should be cancelled to ensure that not transactions are completed.