Skip to main content

Frequently asked questions

For general information and questions, please check in the Knowledge base.

Is Express Checkout available in the ePayment API?

Not yet.

It's possible to implement the ePayment API for everything except Express Checkout, and use the eCom API just for Express Checkout.

With the API platform, you benefit from a shared API framework for all the APIs. This means that all APIs use the same API keys, authentication methods, terminology, and error message formats. Integrating with our APIs is straightforward, and combining functionalities from multiple APIs is easy.

Can payments be "mixed and matched" between the eCom API and the ePayment API?

You can't use the eCom API to do anything with payments initiated with the ePayment API, but you can use the ePayment API to capture, cancel, query, and adjust payments initiated with the eCom API.

See: Migration from the eCom API to the ePayment API.

Are freestanding card payments available in ePayment API in other countries?

Yes. This is available now in Norway, Denmark, and Finland.

Why do I get "PUSH_MESSAGE flow not allowed" error while creating a payment?

Sales units (i.e., Merchant Serial Numbers) must be especially approved to use this user flow. The merchant must have received the phone number from the customer with their consent for sending a payment request to the user's phone via Vipps or MobilePay app. To request this feature, please contact your key account manager, your partner manager, or customer service.

Why do I get "ExpiresAt not allowed" error while creating a payment?

Sales units (i.e., Merchant Serial Numbers) must be especially approved to use this feature. The user experience, including the standard timeout, should be as consistent as possible, so this should only be used in special cases. To request this feature, please contact your key account manager, your partner manager, or customer service.

Why do I get "The parameter PersonalQr is invalid." when initiating payments?

The PersonalQr only accepts the input from the users personal Qr code. This is retrieved by scanning the users Qr code in their Vipps or MobilePay app. If you receive "The parameter PersonalQr is invalid." when initiating payments it means that we cannot recognize the input you are supplying in the request. Double-check the input to ensure that the entire content of the Qr is supplied. And verify that it is the Qr from Vipps or MobilePay app that is scanned and not for example product barcodes or other Qr codes near the scanner.

Why is the receipt not shown when accepting the payment?

The receipt will only be shown when the amount.value and receipt.orderLines.totalAmount are equal and the receipt.orderLines.totalAmount, receipt.orderLines.totalAmountExcludingTax, receipt.orderLines.totalTaxAmount, and receipt.orderLines.taxRate align. If the calculation is not correct, the payment will still be initiated, but the receipt will not be attached to the payment.

Example:

"amount": {
"currency": "NOK",
"value": 1000
},
"receipt": {
"orderLines": [
{
"name": "string",
"id": "1234567890",
"totalAmount": 1000,
"totalAmountExcludingTax": 750,
"totalTaxAmount": 250,
"taxRate": 2550
}
],
"bottomLine": {
"currency": "NOK"
}
}

What happens if the user navigates back to my checkout from the landing page?

If the user does back-navigation in the browser to return to your checkout from the landing page after having submitted their phone number and without confirming the payment, we will cancel the payment. This is to prevent users from paying for the same order twice. Read more about this in the landing page documentation.

Can I lock the payment to only accept payments from one specific user?

Some merchants may not want to allow some users to pay on their platform. It's possible to fix a mobile number in the landing page input field to match the number provided to the create payment request. To use this feature, the merchant must know the user's mobile number. In addition, Vipps MobilePay must add a no_edit_landingpage configuration on the sales unit. Please contact your KAM to request this feature.

What is pspReference?

This is a reference value for a payment, defined by Vipps MobilePay. The reference is globally unique and each payment operation (capture, refund, etc.) will have a unique pspReference.

Why do we get different pspReferences in the API response and the webhook notifications?

When you create a payment we will define a pspReference for this payment. You will receive this in the webhook notification for the payment creation and you can find it in the event log. You will get the same pspReference in the API response to all modification requests (capture, refund, etc.). This pspReference is not specific to the modification, but to the payment. In the modification webhook events you will get a pspReference specific for the modification. Which is why it is different from the pspReference in the API response. The reason for the difference is that the response to the modification API requests is specific to the payment, and not specific to the modification. The webhook notifications are for the specific events, and therefore they have a different pspReference.

Example of the [event log], note how the pspReferences is different for all entries:

{
...
"pspReference": "c70deb91-7684-451c-bac0-e433d66a6be5",
"name": "CREATED",
...
},
{
...
"pspReference": "10000568172",
"name": "AUTHORIZED",
...
},
{
...
"pspReference": "2267200447",
"name": "CAPTURED",
...
},
{
...
"pspReference": "2268200548",
"name": "REFUNDED",
...
}

Help us improve our documentation

Did you find what you were looking for?