Frequently asked questions

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

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 are the order details not shown when accepting the payment?

The order details 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 order details will not be attached to the payment.

Example:

"amount": {
"currency": "NOK",
"value": 1000
},
  "receipt": {
    "orderLines": [
      {
        "name": "string",
        "id": "1234567890",
        "totalAmount": 1000,
        "totalAmountExcludingTax": 800,
        "totalTaxAmount": 200,
        "taxRate": 2500
      }
    ],
    "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?

The pspReference is a unique identifier defined by Vipps MobilePay. It can represent either a payment or an event, and every payment operation (e.g., capture, refund, or cancel) will have its own unique pspReference.

For the following API requests, the pspReference provided in the response will match the CREATED event:

• Get a payment
• Cancel a payment
• Capture a payment
• Refund a payment

When you request Get a payment's event log, the response will include an array of events. In this case:

• Each event will have its own pspReference, serving as its unique identifier.
• The reference value in the array will be the globally unique identifier for the payment itself.

Here's an example of the event log. You'll see that the pspReference is different for each entry.

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

See: Why does the pspReference differ between API responses and webhook notifications

Why does the pspReference differ between API responses and webhook notifications?

• API responses focus on the payment as a whole, so they use the payment-level pspReference.
• Webhooks reflect individual events, which is why they use their own references.

There are two types of pspReferences in play:

• Webhook version
• Payment version

They're not the same. Here’s how it works:

For payments

When you create a payment, we assign a pspReference to the payment. This reference:

• Shows up in the webhook notification for payment creation.
• Can be found in the event log.
• Is included in API responses for modification requests (like capture or refund).
• It represents the payment itself—not the specific modifications.

For modifications

Webhook notifications for modifications (capture, refund, etc.) have their own unique pspReference. These are tied to the specific event, not the payment.

When does ePayment send notifications for payments?

• When an ePayment is created, a push notification is sent to the customer, informing them that the payment requires approval.
• If the payment is not approved or completed, no additional notifications (neither daily push notifications nor SMS messages) are sent.
• The status of the payment remains available in the app, where the customer can see that it still requires action.

Other questions?

Do you have other questions?

For more payment questions, see the Knowledge base payment FAQ.

If you still can't find what you're looking for, let us know in the feedback form below.