Vipps Norway: wallet and pay-in

1) Context and positioning of Vipps

Vipps is a Norwegian mobile wallet/superapp used for P2P, P2M (e-commerce/offline), invoices and re-debits. The user confirms transactions using BankID (SCA), money moves along bank rails, and the merchant receives online status and subsequent crediting. Vipps is popular in retail and online trading, reducing friction compared to cards.

• Telephone addressing (P2P and P2M) + payment links/QR.
• App2App experience: quick transition from checkout to Vipps and back.
• SCA/BankID and low fraud against CNP cards.
• Low cost/easy integration through PSP and ready-made widgets.

2) Roles and participants

Vipps (schema/provider) - rules, member catalogs, brand and API.
Participating banks - holders of customer accounts/cards, limits and anti-fraud.
PSP/acquirers - connect the merchant to Vipps (checkout/invoice/QR), give SDKs, web hooks and reports.
Merchant - initiates payment/request, processes statuses and returns, conducts reconciliation.
Payer - confirms transactions in Vipps/BankID.

3) Channels and user scenarios

3. 1 P2P (per phone)

The sender selects the contact → enters the amount/note → confirms through BankID → the recipient instantly sees the loan on the account.

3. 2 Pay-in для e-commerce (Vipps på Nett / Checkout)

App2App/Deeplink: on the check, the merchant transfers the amount and metadata → Vipps opens → the user confirms → return to the cashier with the status.
Pay-by-Link: invoice/link in SMS/email/messenger; convenient for accounts and B2B.
QR per-order: dynamic QR with amount and 'orderId' (for desktop/offline); scan → confirmation in Vipps.

3. 3 POS/offline (Vippsnummer/QR)

At the checkout, a dynamic QR or short merchant number is shown; the amount is fixed in advance or entered by the buyer.
Confirmation - via Vipps/BankID, the check is visible in the application and at the merchant.

3. 4 Request-to-Pay/Invoice (Vipps Faktura)

Merchant sends a request for payment with the amount, purpose and term → the payer confirms in Vipps → the payment goes like a regular transfer.

3. 5 Repeated write-offs

Basic Vipps - one-off with SCA. For subscriptions, use the first payment → mandate (through the bank/PSP: e-mandate/AvtaleGiro/Open-Banking) for future write-offs with a limit/frequency.

4) Statuses and timings

Typical statuses are 'initiated' → 'pending' → 'success '/' failed '/' cancelled '/' expired'.
For requests: 'requested '/' expired'.
Settlement: bank credit in the nearest operating window; reporting still needs a daily recon.

5) Limits and risk policies

• Per-transaction, per-day/24h, sometimes weekly/monthly.
• New receiver/merchant - reduced thresholds and/or shutter speed.
• Channel limits: P2P, e-commerce (App2App/QR/Link), POS, invoices.
• Velocity/device/geo-rules on the bank side and Vipps.

6) Economics and commissions

For merchant, Vipps are usually cheaper than card MDR, but conditions differ between PSPs (fix/low% + widget fees/reports).
Consider operating costs: 'pending/expired' support, disputes, recon, and SLA monitoring.

7) Returns and disputes

Chargeback as in card schemes is absent. Return - new credit transaction from merchant to payer; partial refunds are allowed.
Terms - bank (often T + 0/T + 1).
Disputes/complaints - according to PSP/bank procedures: keep order logs, confirmation of service/delivery.

8) Safety and compliance

SCA through BankID, device binding and bank risk scoring.
PII minimization: store only the required attributes (phone/refs), encrypt PII, restrict access (RBAC).
Webhooks: HMAC/nonce, replay protection, timestamps, event deadpan.
Compliance with PSD2/GDPR and local requirements (Finanstilsynet).

9) Merchant integration

Options

1. Hosted/Embedded by PSP - fast start, App2App/QR/Link out of the box.
2. Server-to-Server + App2App/QR - native UX, dynamic QR per-order, fine error handling.
3. Pay-by-Link/Invoice - invoice in SMS/email/messenger with confirmation in Vipps.

• API: `createPayment`, `requestToPay`, `refund`, `webhook`, `reconcile`.
• Idempotence ('orderId' + key), exponential retrays, event dedup.
• Recon: daily auto-recon + periodic full-recon; storage of UTR/bank reference.
• SLA dashboards: conversion, 'pending→success/expired', latency before enrollment/return.

10) Reconciliation and Reporting

Log: 'paymentId/transactionId', 'orderId', channel (App2App/QR/Link/POS), payer phone/alias, status, amount/currency, timestamp, UTR.
From PSP/bank: registers of credits/returns/corrections and late status updates.
Set alerts by out of sync and hanging 'pending'.

11) UX patterns

Mobile-first: on mobile - App2App; on a desktop, a large dynamic QR with a timer.
Transparent errors: limit, SCA/BankID failure, timeout; safe repeat and alternative (card/SEPA/other A2A).
Receipt: amount, time, 'transactionId', channel, UTR, support contacts.
Validity period for QR/requests + clear recovery scenario.

12) Recurrence and mandates

Use Vipps First Payment (SCA) → Mandate (AvtaleGiro/OB-mandate).
In the mandate, fix the limit per debit, frequency, write-off window, notifications; give the user the control screen (pause/cancel/update).

13) High-risk verticals (including iGaming)

Channel availability and limits are determined by bank/PSP policies and local law.
Expect lowered thresholds, enhanced ACC/monitoring, possible hold's.
Plan alternative rails (cards, SEPA, other PIS) and smart-routing by risk/channel/bank.

14) "Vipps Gateway" architecture

API layer (REST/GraphQL) for cash register/back office.
Event queues: status events → billing/CRM/analytics.
Security: vault for secrets, IP-allowlist PSP, strict redirect-URI validation, anti-replay tokens.
Observability: channel conversion (App2App/QR/Link/POS), fraction of 'pending→expired', time to settlement/return.

15) Output checklist

1. Connect Vipps at PSP/bank, select channels (App2App/QR/Link/POS).
2. Implement 'createPayment '/' requestToPay', dynamic QR, error/limit screens.
3. Connect webhooks, idempotency, retrai and event dedup.
4. Set up recon (daily + full), UTR/fin references storage.
5. Support partial/full refunds and ODR procedures.
6. Start SLA dashboards and alerts (conversion/latency/hung statuses).
7. Conduct e2e tests with main banks/devices and offline points (if relevant).

Limit Reference Card

Per-txn/24h/7d: store in config and check before starting.
New recipients/merchants: lowered thresholds/shutter speed.
Channels: separate limits for P2P, e-commerce (App2App/QR/Link), POS, invoices/payment requests.
Velocity/risk: Bank antifraud can gently deflect/slow down operations.

Summary

For online - App2App + dynamic QR, for offline - QR/POS, for simple transfers - P2P to the phone.
Separate online confirmation and final credit in logic; build around webhooks + recon and partial refunds.
Do not fix the amounts: keep limit configs by bank/channel, update regularly.
For subscriptions, the first Vipps bundle → a ticket with transparent management and notifications.