Checklist

Endpoints to integrate

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

Endpoint	Comment
Create payment	`POST:/epayment/v1/payments`
Get Payment	`POST:/epayment/v1/payments/{reference}`
Get Payment Event log	`POST:/epayment/v1/payments/{reference}/events`
Cancel payment	`POST:/epayment/v1/payments/{reference}/cancel`
Full and Partial capture payment	`POST:/epayment/v1/payments/{reference}/capture`
Full and partial refund payment	`POST:/epayment/v1/payments/{reference}/refund`

Action	Comment
Handle responses	Make sure to handle all responses and states from the payment: `CREATED`, `ABORTED`, `EXPIRED`, `CANCELLED`, `CAPTURED`, `REFUNDED`, `AUTHORIZED` and `TERMINATED`.
Handle errors	Make 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 headers	Send 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 history	We 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".

Action	Comment
Send useful `reference`	Follow our reference recommendations.
Poll for payment details	The 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 redirects	The 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 guidelines	The Vipps MobilePay branding must be according to the design guidelines.
Educate customer support	Make 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 portal.vipps.no for normal work.

The merchant orders Vipps på Nett.
Vipps MobilePay completes customer control (KYC, PEP, AML, etc.).
The merchant receives an email from Vipps saying that they can log in with BankID on portal.vipps.no and retrieve API keys.
The merchant completes all checklist items above. Please double-check to avoid mistakes.
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.
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 portal.vipps.no.
- 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 portal.vipps.no as soon as the customer control (see step 2) is completed, independently of this checklist.
The merchant goes live 🎉