Point of Sale integrations

Point of Sale (POS) integrations enable in-person payment experiences at physical locations like retail stores, restaurants, and service providers. Whether you're using a customer-facing screen, QR scanner, manual entry system, or unmanned point of sale, Vipps MobilePay provides flexible integration options to meet your needs.

In-person payment scenarios:

• Customer-facing screen - Display a dynamic QR code for customers to scan
• QR scanner - Scan the customer's personal QR code from their app
• Manual entry - Cashier enters the customer's phone number
• Static QR - Unmanned locations like vending machines or self-service kiosks

See In-person payments for detailed implementation flows for each scenario.

This guide covers specific integration considerations for POS systems, including QR code usage, multi-location refunds, distance selling requirements, and the go-live process.

The process to go live in production

1. The partner establishes a customer relationship with Vipps MobilePay. See: Apply for services.
2. The partner integrates the POS system with Vipps MobilePay and completes the integration checklist for the APIs they are using. The partner now has a working POS integration. This process normally takes 1–4 days.
3. The partner's merchant establishes a customer relationship with Vipps MobilePay. See: Apply for services. This process normally takes 1–4 days.
4. If the merchant already has a customer relationship with Vipps MobilePay, a new sales unit must be created, with skipLandingPage activated. The customer center can help with this. See: landing page.
5. Set up API keys according to your integration model. See: API keys for POS integrations.
6. The partner configures the merchant's POS system for Vipps MobilePay.
7. The merchant can now accept Vipps MobilePay payments at the point of sale.

Skipping the landing page

POS integrations can be whitelisted to skip the landing page, providing a faster checkout experience. When enabled, customers proceed directly to payment authorization without seeing an intermediate landing page.

See: Skip the landing page for details on how to get whitelisted.

API keys for POS integrations

POS integrations should typically use Partner keys rather than separate API keys for each merchant. Partner keys simplify key management when integrating multiple merchants and allow you to authenticate on behalf of your merchants using their Merchant Serial Number (MSN).

Using Partner keys (recommended):

Partner keys enable you to manage multiple merchants through a single set of credentials. You authenticate using your partner keys and specify which merchant you're acting on behalf of by including their MSN in your API requests.

See: Partner keys for setup and implementation details.

Using individual merchant API keys:

If you're not using Partner keys, each merchant must retrieve their API keys from the business portal and provide them securely to you. This approach requires managing separate credentials for each merchant, which can be more complex at scale.

The best approach depends on your specific integration architecture and the number of merchants you serve.

Signing up merchants

Partners who integrate Vipps MobilePay into their POS systems can sign up multiple merchants through a streamlined process. This is useful for POS vendors, payment service providers, and other partners who serve multiple merchants.

See: Partners: How to sign up new merchants for the complete signup process.

Provide order details

How to provide order details:

• ePayment API: Include order details directly when creating the payment using the receipt property. This allows customers to view the order details in their app immediately after payment.
• eCom API (legacy): Use the Order Management API to send order details to existing transactions.

As an alternative to digital receipts, an online sales log must be available for compliance.

User anonymity in transactions

If your POS integration allows the cashier to enter the customer's phone number, you may store it in compliance with GDPR and other applicable data protection regulations.

For more information about user data and privacy, see User data & privacy.

Handling refunds on behalf of other locations

It may be relevant for enterprise setup, omnichannel, multiple physical locations within the same chain to refund orders on behalf of other locations.

Prerequisites: Your locations or your centralized system must have access to all location credentials or use Partner keys. Locations must be able to search for the order reference ID from other locations or request it from the centralized system.

User story: A user buys a product from "Store A". The user then visits Store B to return some goods. "Store B" wants to be able to refund on behalf of "Store A".

Problem: Refunds can only be performed by the sales unit where the payment originated from: "Store A".

Recommended solutions:

A: Partner keys are used for all locations:

Locations must be able to search for orderId for payments made in other locations. The cashier can then search and select orderId from "Store A" and click refund.
Technical: Use Partner keys to authenticate, add Merchant-Serial-Number from "Store A" to the request header and original orderId to the refund request.

NB: With Partner keys, do not let the cashier input Merchant-Serial-Number themselves. These must be locked and connected to the location selection to reduce risk of adding the wrong location.

B: Partner keys are not used:

In this case, a centralized system needs to store credentials from all sales units within the enterprise. "Store B" must be able to request a refund from the central system based on the original orderId and location for the order origin ("Store A"). Technical: Use "Store A" credentials to authenticate, add original orderId to the refund request.

C: Same sales unit is used for all locations:

It is possible to use one sales unit (one MSN) for all locations and use a prefix in the reference (also called orderId) to identify which orders belong to which locations. This will result in having one settlement for all. You decide what the reference contains, and it may be up to 50 characters. See: Recommendations for reference and orderId. You will use the same API keys for all locations.