Skip to main content

Frequently asked questions

Vipps Only available for Vipps. All new integrations use the ePayment API.

Here are the eCom API Frequently Asked Questions (FAQ). See the eCom API guide for all the details.

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

Common problems​

See Knowledge base: Errors for more questions.

Why does Vipps Hurtigkasse (express checkout) fail?​

When using Vipps Hurtigkasse (express checkout), Vipps makes a callback to the merchant's server to retrieve the merchant's shipping methods for the user's address. Vipps sends the user's address (with the user's consent) to the merchant, and the merchant responds with the shipping methods and cost.

If the merchant's server is slow, or has a slow internet connection, the delay may cause Vipps Hurtigkasse to fail due to a timeout.

The solution to this is a faster server and internet connection, or to provide the shipping methods as part of the payment initiation. See: Express checkout API endpoints required on the merchant side.

Please note: If you are not shipping any products you should use Userinfo instead of Vipps Hurtigkasse, to avoid asking the customer in a pub for the shipping method for the drinks, etc.

We strongly recommend checking the full history of every Vipps payment with the API: You can see if a payment has been actively rejected, if the user has not done anything, etc. See: Get payment details.

See: All errors.

Reserve and capture​

Refunds​

Can I refund a payment?​

The eCom API supports refunds with POST:/ecomm/v2/payments/{orderId}/refund.

All integrations with the eCom API must support refunds.

It is also possible to do refunds on portal.vippsmobilepay.com.

Refunds can be made up to 365 days after payment or reservation. Very old payments have a higher risk of being problematic, because people change banks, leave the country, die, etc., and this then requires time-consuming manual work. We therefore limit refunds to 365 days.

How can I refund only a part of a payment?​

Example: A customer has placed an order of two items for a total of 1000 NOK. The merchant has initiated a payment of 1000 NOK, but the customer has changed her mind and only bought one of the items, with a price of 750 NOK. The merchant has therefore made a partial capture of 750 NOK, and need to refund the remaining 250 NOK.

The partial capture (the 750 of the 1000 NOK in the example above) is normally confirmed in the bank after 3-10 days, but it sometimes takes even longer. When this is done, the bank will make the remaining (250 NOK) available in the customer's account again. This process depends entirely on the customer's bank, and we can't speed it up.

Banks keep reservations for the same number of days regardless of whether there has been one or more captures. Banks do not extend the reservation if a partial capture has been made.

If a partial capture has been made, the bank cancels the reservation for the remaining amount. If no capture has been made, the entire reserved amount is cancelled. Banks "count the days" from when the reservation was made, so the merchant must make the capture, or all captures, before the reservation expires.

See: Settlements.

Users and payments​

See FAQ: Users and payments for more questions.

I have initiated an order but I can't find it​

If you have multiple sales units: Make sure you use the correct API keys, and that you are not attempting to use one sales unit's API keys to retrieve an order made by a different sales unit.

Have you, or the eCommerce solution you are using, successfully implemented GET:/ecomm/v2/payments/{orderId}/details? This is a requirement, see the API checklist.

In case the callback fails, you will not automatically receive notification of order status. The solution is to check with GET:/ecomm/v2/payments/{orderId}/details.

See: API endpoints.

Common errors​

See FAQ: Common errors for more questions.

Why do I not get callbacks from Vipps?​

Please make sure the URLs you provide to Vipps are reachable from outside your own environment.

Have a look at the Callback section in the API guide, and see How to test your own callbacks.

If you do not receive a callback, it could be because your firewall is blocking our requests. See: Vipps request servers.

Please check your own logs for any signs of problems. If your orderId is acme-shop-123-order123abc: Search your logs for acme-shop-123-order123abc.

Why do I get Payment failed?​

This error is shown in Vipps if you use Vipps Hurtigkasse (Express checkout) and respond incorrectly to the request for [shippingDetailsPrefix]/v2/payments/{orderId}/shippingDetails.

Please verify that your response is correct.

Also consider using static shipping methods, as it gives a faster payment process and a better user experience.

Why do I not get the sub from /details?​

If you use the correct scope in the payment initiation, but don't get the sub in the response for /details: Check that you are following the orderId recommendations. Very short orderId values don't work well with our database index, and may cause an internal timeout, and we "have to" send the response without the sub. We cannot enforce longer orderId values due to backwards compatibility.

Other questions​

What functionality is included in the eCom API, but not the PSP API?​

The PSP API provides tokens that a PSP can use to charge a Vipps user's card. To put it simply, it is a "card token lookup service". The payment is completed by the PSP, who sends an update to Vipps about the success or failure.

The eCom API has some functionality that is not available in the PSP API:

  1. Retry functionality: If the user attempts to pay with a card that is declined, the user can retry with a different card, while still in the same payment process. This results in a higher success rater for payments. The PSP API does not have this functionality, as it is the PSP, not Vipps, that make the charge.
  2. Express checkout (Vipps Hurtigkasse) is only available in the eCom API.
  3. Userinfo: The eCom API offers the possibility for merchants to ask for the user's profile information as part of the payment flow: name, address, email, phone number, birthdate, etc.
  4. When using the eCom API, Vipps handles soft-declines, 3-D Secure, BankID, etc. There is nothing a merchant needs to do. This give a consistent user experience and a very high completion rate.

What does the status suffix at the fallBack URL mean?​

Please disregard it. The status suffix was phased out several years ago, and is no longer documented. But, since some merchants still depend on in, it still provided.

How do I use the one-time payment QR?​

This feature is for presenting a QR code for opening a payment request from a customer-facing screen, so there is no need to manually input the mobile number.

Basic flow:

  1. Initiate a eCom payment (skipLandingPage must be set to false)
  2. Receive the payment URL as response
  3. Post the payment URL to the QR API
  4. Receive a URL to a QR code in PNG (Portable Network Graphics) format
  5. Present the QR code on the customer-facing screen
  6. The user scans the QR code with the Vipps or MobilePay app, or the camera app
  7. The user pays (or cancels the payment) in the app
  8. The fallback URL is triggered and will be presented on customers mobile phone

Please note: The customer-facing screen will not show the fallback page. We recommend presenting the result of the payment in some other way on the screen, and also that an error messages if something went wrong.

If it is not possible for the POS solution to handle a fallback URL, you may set fallbackURL to be the merchant's website.

See also:

Help us improve our documentation

Did you find what you were looking for?