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
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
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
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
Read more about Invoice Issuer on GitHub here
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.
When testing Invoice, then you'll use the Invoice User Simulation API that you'll find here. To create an Invoice, you must supply
- Authenticated user id
- 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 firstname.lastname@example.org
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|
|a6d8044d-176b-4639-a55f-d14d1ae11e28||+4599592431||Test name||Card is expired. Use this testuser to test error handling for failed card scenarios|
|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.|
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.
|Invoice has not been visualized.||Hypothetical error|
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
ApiKey authentication method your provided API key will be simply added to
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.
invalidtwo additional fields will be added:
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
Href to the page where MobilePay users can accept an invoice, e.g.:
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.