Step 2. Invoice Test

In this section, you will find information on testing, as well as test data. All users, items, and payment involved in Sandbox transactions are fictitious. You are able to test all the Invoice features, just as they are in the production environment. However, it is not possible to interact with the MobilePay app, therefor it is not possible to accept or reject invoices from the app. Instead, you have access to a testing API: Invoice User Simulation API , which makes it possible to imitate user actions

Making the first call - Invoice 

Step 1. Get Tokens

When you have gone through OpenID Connect, then you can start calling the API. All calls to Invoice endpoints require access tokens, and they are used to make API requests on behalf of a user.  The content of the header should look like the following. We recommend you start with getting the MerchantId . 

Step 2. Get MerchantId

MerchantId is a unique identifier of a merchant in our system. After you retrieve an access token from OpenID flow use the following endpoint to retrieve your MerchantId.

GET /api/v1/merchants/me



Step 3. Get Invoice Issuer 

Afterwards you should get an invoice issuer. Invoice issuer represents merchant’s company information. The merchant is the customer company and the Invoice Issuer is the actual service provider name under which they create invoices

GET /api/v1/merchants/{merchantId}/invoiceissuers

Read more about Invoice Issuer on GitHub here 

Test Actions 


1. Create an InvoiceDirect
2. Create multiple InvoiceDirect
3. Cancel an unpaid Invoice


4. Create an Invoice Link
5. Create multiple InvoiceLink
6. Test User Consent for Invoice Direct 


Invoice - Testing 

When calling the testing API, you must always supply an authenticated user id. We supply a testing API, Invoice User Simulation, that simulates user actions in the app. With the API, you can: 

  • Get an Invoice PDF 
  • Accept an Invoice
  • Reject an Invoice 
  • Test User Consent 

We expect that you have simulated the 4 features listed above, before you start the verification process. Then it can be completed in a day. You should test both InvoiceDirect and InvoiceLink.

Test users and test data

When testing Invoice, then you'll use the Invoice User Simulation API that you'll find here. To create an Invoice, you must supply

  1. Authenticated user id
  2. ConsumerCard
  3. Phone number 

Below you can find a list of test users for Denmark and Finland. If there is an issue with a test user, please try a different user, or contact us at

Note: When testing Invoice payments in Sandbox remember to use the same authenticated user id for both creating and approving the invoice.


Authenticated user id ConsumerCard Phone number Consumer name Note


+4557373259 Test name  


 a6d8044d-176b-4639-a55f-d14d1ae11e28 +4599592431 Test name Card is expired. Use this testuser to test error handling for failed card scenarios


 4dacb7cd-3a73-4e4b-9479-62a3c59e37b0 +4522509895 Test name  


 6cdf304d-d4c5-4126-9775-a286ce16838b  +4554048573 Test name  


 d17f4d77-e956-4b78-aa67-626866d3d34a  +4585155935 Test name  

Authenticated user id ConsumerCard Phone number Consumer name
404f38dd-25dd-4683-831c-a85f1d25b64d bd0c4cb8-847e-41f0-9dec-914a1e59b829 +358806041406 FI Test name
d5ae8716-4f28-49cc-926b-9667cdeed27a 5efac6d4-1c6b-42e9-a14e-d15f145fe429 +358806041436 FI Test name
6b6c72bc-4a90-4cf7-ada1-c0318cc5404d 3d23e95d-c901-4d23-875d-bcb91239cfaa +358806041507 FI Test name
04e1f1d4-47e1-4db9-8f0e-35b29e380890 d1d0db23-1662-449b-aee8-1668b900b477 +358806041536 FI Test name

To accept an Invoice, you also need to supply a valid ConsumerCard. 
Note: You cannot use the MobilePay app installed on your phone when you are testing in sandbox environment. As there is no sandbox MobilePay app, you will instead use the Invoice User Simulation API to simulate customer actions.
Error codes

Generally speaking, it means one of two things - something was wrong in your request or the API could not parse the passed data. The good things about error codes is that they both clarify the situation, and communicate the intended functionality.

You will find Error Codes for Invoice on GitHub here 

If you encounter error 10502, you will not find it on GitHub, because that is an user facing error, an error you might get when using the Invoice User Simulation API to imitate user in Sandbox. 

 Error code

Error Description



Invoice has not been visualized.  Hypothetical error 
Callbacks - MobilePay Invoice 

In order to receive callbacks about status changes for an invoice a callback URL must be specified first. But before setting your callback URL you must choose prefered authentication method which we will use for authenticating our requests when calling your callback URL. Currently we support Basic and ApiKeyauthentication methods:

PUT /api/v1/merchants/{merchantId}/auth/basic
PUT /api/v1/merchants/{merchantId}/auth/apikey

Using ApiKey authentication method your provided API key will be simply added to Authorizationheader.

Example of our callback body:

"ErrorMessage":"<description of error>",

All possible invoice statuses returned in callback body can be found in Get invoice status section.

Note: When status of an invoice is invalid two additional fields will be added: ErrorCode and ErrorMessage. All possible validation errors can be found in validations section.

Callbacks about created InvoiceLinks which were created asynchronously using batch endpoint will contain additional field Links with Rel="user-redirect" and Href to the page where MobilePay users can accept an invoice, e.g.:

Step 3. Invoice Verification

Once you have finished testing the Invoice API in sandbox, you have to go through a small verification process, to ensure that your system is ready for production.