Skip to main content


Endpoints to integrate

Integrate all the API endpoints. For examples of requests and responses, see the Postman collection and environment.

Create paymentPOST:/epayment/v1/payments
Get PaymentPOST:/epayment/v1/payments/{reference}
Get Payment Event logPOST:/epayment/v1/payments/{reference}/events
Cancel paymentPOST:/epayment/v1/payments/{reference}/cancel
Full and Partial capture paymentPOST:/epayment/v1/payments/{reference}/capture
Full and partial refund paymentPOST:/epayment/v1/payments/{reference}/refund

Quality assurance

Handle responsesMake sure to handle all responses and states from the payment: CREATED, ABORTED, EXPIRED, CANCELLED, CAPTURED, REFUNDED, AUTHORIZED and TERMINATED.
Handle errorsMake sure to log and handle all errors. All integrations should display errors in a way that the users (customers and merchant employees/administrators) can see and understand them.
Include HTTP headersSend the HTTP headers in all API requests for better tracking and troubleshooting (mandatory for partners and platforms, who must send these headers as part of the checklist approval).
Add information to the payment historyWe recommend using the Order Management API to add receipts and/or images to the payment history. This is a great benefit for the end user experience. It is also mandatory for merchants using "Vipps Assisted Content Monitoring".

Avoid integration pitfalls

Send useful referenceFollow our reference recommendations.
Poll for payment detailsThe Merchant must not rely on fallback or callback alone, and must poll GET:/ecomm/v2/payments/{orderId}/details as documented (this is part of the first item in this checklist, but it's still a common error). Follow our polling recommendations.
Handle redirectsThe merchant must handle that the fallback URL is opened in the default browser on the phone, and not in a specific browser, in a specific tab, in an embedded browser, requiring a session token, etc. Follow our recommendations regarding handling redirects. See the FAQ: How can I open the fallback URL in a specific (embedded) browser?
Follow design guidelinesThe Vipps MobilePay branding must be according to the design guidelines.
Educate customer supportMake sure your customer service, etc. has all the tools and information they need available in your system, through the APIs listed in the first item in this checklist, and that they do not need to visit for normal work.

Flow to go live for direct integrations

  1. The merchant orders Vipps på Nett.
  2. Vipps MobilePay completes customer control (KYC, PEP, AML, etc.).
  3. The merchant receives an email from Vipps saying that they can log in with BankID on and retrieve API keys.
  4. The merchant completes all checklist items above. Please double-check to avoid mistakes.
  5. The merchant verifies the integration in the test environment by checking that there are test IDs (reference) in the test environment, with the following states:
    • A complete order ending in CAPTURED (/capture request).
    • A complete order ending in REFUNDED (/refund request).
    • A complete order ending in CANCELLED (/cancel request).
    • In the test environment, this must be verified using the API itself.
  6. The merchant verifies the integration in the production environment (similar to step 5):
    • A complete order ending in AUTHORIZED, CAPTURED, REFUNDED and CANCELLED request.
    • We recommend checking this using both the API itself and the API Dashboard, available under Utvikler on
    • Please note: Vipps does not do any kind of activation or make any changes based on this checklist. The API keys for the production environment are made available on as soon as the customer control (see step 2) is completed, independently of this checklist.
  7. The merchant goes live 🎉

Flow to go live for direct integrations for partners

See: Vipps partners.