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.

What do all the errors mean?

Here is an overview of errors you may get from the ePayment API. They should be self-explanatory, but please let us know if they can be improved.

Errors responses have this format:

{
   "type":"http://example.com",
   "title":"string",
   "detail":"string",
   "traceId":"string"
}

We will change the above format to match the common HTTP response codes and errors format by changing traceId to instance. The ePayment documentation will be updated when that is done.

Important: The unique identifier of an error is the type. When handling errors, you must always identify the type of error by the type field. The title and description may be updated at any time, without warning, to improve the API and make the error messages easier to understand.

Title	Description	Comment
Amount too small	The amount is too small. Amounts are specified in minor units, like øre or cent.	The minimum amounts allowed are NOK 100 øre, DKK 1 øre, EUR 1 cent.
Amount invalid	The amount is invalid. Amounts must be integers, no decimals. They are specified in minor units, like øre or cent.	A common error is to specify amounts with decimals, sometimes due to rounding errors.
Express payment not allowed	Express payment is not allowed for this sales unit.
Missing static shipping details	Express payments with static shipping details require a list of shipping options.
No cards	The user does not have any payment cards.	The user must add a valid card in the app.
Payment limit exceeded	The merchant's payment request limit is exceeded.
Operation not supported	The attempted payment operation is not supported.
Capture amount too high	The total capture amount exceeds the reserved amount. Cannot capture a higher amount than the amount the user has accepted. Check the payment details.
Cannot capture before reservation	The amount you tried to capture is not reserved. The user must accept the payment before capture can be done.
Cannot capture a cancelled payment	Cannot capture a payment that has been cancelled. Check the payment event log.	See Cancellations and GET:/epayment/v1/payments/{reference}/events.
Capture period expired	After reservation, payments can only be captured within the payment time limits.	See Reserve and capture.
Capture idempotency conflict	The capture request in an idempotent retry must be identical to the previous request(s).	See Idempotency.
Cannot cancel a captured payment	Cannot cancel a payment that has been captured. Check the payment event log.	See Cancellations and GET:/epayment/v1/payments/{reference}/events.
Cannot cancel a non-reserved payment	Cannot cancel a payment that is not reserved. Check the payment event log.	See Cancellations and GET:/epayment/v1/payments/{reference}/events.
Cancel period expired	After reservation, payments can only be canceled within the payment time limits.	See Cancellations.
Cannot cancel pending	Cannot cancel a pending payment.	See Cancellations.
Order processing	Too many concurrent requests. The payment is being processed.
Internal error	Internal error. This may be caused by an incorrect API request. Please check the request. See the status page.
Payment already refunded	Cannot refund a payment that has already been refunded. Check the payment event log.	See GET:/epayment/v1/payments/{reference}/events.
Not enough refundable	Cannot refund more than the available amount. Check the payment event log.	See GET:/epayment/v1/payments/{reference}/events.
Refund period expired	Payments can only be refunded within 365 days of the reservation.	See Reserve and capture.
Refund idempotency conflict	The request in an idempotent retry must be identical to the previous request(s).	See Idempotency.
Attempted refund before reservation	Cannot refund a payment that is not reserved. Check the payment event log.	See and GET:/epayment/v1/payments/{reference}/events.
Invalid phone number	The phone number is invalid. Phone numbers must be in MSISDN format: Country code and subscriber number, but no prefix.
Customer not found	The phone number does not belong to a Vipps or MobilePay user, or the user cannot pay businesses. We cannot give more details.
Idempotency error	Reference acme-shop-123-order123abc already exists.	See Idempotency.
Reference not found	The reference acme-shop-123-order123abc does not exist for MSN 123456
Idempotency error	Idempotency-Key 49ca711a-acee-4d01-993b-9487112e1def already exists.	See Idempotency.
Invalid URL	The parameter http://example.com is invalid.
Missing required parameter	The parameter something-something is required.
Direct capture not allowed	The sales unit with MSN 123456 is not allowed to use direct capture.
Reserve capture not allowed	The sales unit with MSN 123456 is not allowed to use reserve capture.
Skip landing page not allowed	The sales unit with MSN 123456 is not allowed to skip the landing page.
PUSH_MESSAGE flow not allowed	The sales unit with MSN 123456 is not allowed to use PUSH_MESSAGE flow.
Long-living payment not allowed	The sales unit with MSN 123456 is not allowed to perform long-living payment requests.
Payment cannot be cancelled	Reference acme-shop-123-order123abc cannot be cancelled. Invalid state: something-something.	See Cancellations.
Payment cannot be refunded	Reference acme-shop-123-order123abc cannot be refunded. Invalid state: something-something.
Payment cannot be captured	Reference acme-shop-123-order123abc cannot be captured. Invalid state: something-something.
Payment cannot be created	Reference acme-shop-123-order123abc cannot be created. Invalid state: something-something.
Payment is already reserved	The payment with reference acme-shop-123-order123abc has already been reserved.
Invalid scope	The scope something-something is invalid.
Illegal scope	The scope something-something is illegal. Are you asking for more than you are allowed to?
Approve failed	Force approve payment failed (this is only available in the test environment). Reason: something-something.
Expiration date invalid	The expiration date something-something is invalid.
ExpiresAt not allowed	Cannot set ExpiresAt for flow something-something.

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.