Vipps Норвегія: гаманець і pay-in
1) Контекст і позиціонування Vipps
Vipps - норвезький мобільний гаманець/суперапп, що використовується для P2P, P2M (e-commerce/офлайн), інвойсів і повторних списань. Користувач підтверджує операції за допомогою BankID (SCA), гроші рухаються по банківських рейках, а мерчант отримує онлайн-статус і подальше зарахування. Vipps популярний в роздробі та онлайн-торгівлі, знижуючи тертя в порівнянні з картами.
Ключові властивості:- Адресація по телефону (P2P і P2M) + платіжні посилання/QR.
- App2App-досвід: швидкий перехід з чекаута в Vipps і назад.
- SCA/BankID і низький фрод щодо карт CNP.
- Низькі витрати/проста інтеграція через PSP і готові віджети.
2) Ролі та учасники
Vipps (схема/провайдер) - правила, каталоги учасників, бренд і API.
Банки-учасники - власники рахунків/карток клієнтів, ліміти та антифрод.
PSP/еквайєри - підключають мерчанта до Vipps (checkout/інвойс/QR), дають SDK, веб-хуки і звіти.
Мерчант - ініціює оплату/запит, обробляє статуси і повернення, веде звірку.
Платник - підтверджує операції в Vipps/BankID.
3) Канали і призначені для користувача сценарії
3. 1 P2P (на телефон)
Відправник вибирає контакт → вводить суму/замітку → підтверджує через BankID → одержувач миттєво бачить кредит на рахунку.
3. 2 Pay-in для e-commerce (Vipps på Nett / Checkout)
App2App/Deeplink: на чекауті мерчант передає суму і метадані → відкривається Vipps → користувач підтверджує → повернення в касу зі статусом.
Pay-by-Link: інвойс/посилання в SMS/email/месенджері; зручний для рахунків і B2B.
QR per-order: динамічний QR з сумою і'orderId'( для десктопа/офлайну); скан → підтвердження в Vipps.
3. 3 POS/офлайн (Vippsnummer/QR)
На касі показується динамічний QR або короткий номер мерчанта; сума фіксується заздалегідь або вводиться покупцем.
Підтвердження - через Vipps/BankID, чек видно в додатку і у мерчанта.
3. 4 Request-to-Pay/Інвойс (Vipps Faktura)
Мерчант відправляє запит на оплату з сумою, призначенням і терміном → платник підтверджує в Vipps → оплата проходить як звичайний переказ.
3. 5 Повторні списання
Базовий Vipps - one-off з SCA. Для підписок використовують перший платіж → мандат (через банк/PSP: e-mandate/AvtaleGiro/Open-Banking) для майбутніх списань з лімітом/періодичністю.
4) Статуси і таймінги
Типові статуси: `initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
Для запитів: `requested` / `expired`.
Settlement: банківський кредит у найближчому операційному вікні; для звітності все одно потрібен щоденний recon.
5) Ліміти та ризик-політики
Ліміти визначаються банком/PSP і залежать від профілю клієнта і каналу:- Per-transaction, per-day/24h, іноді weekly/monthly.
- Новий одержувач/мерчант - знижені пороги і/або витримка.
- Канальні ліміти: P2P, e-commerce (App2App/QR/Link), POS, інвойси.
- Velocity/девайс/гео-правила на стороні банку і Vipps.
6) Економіка та комісії
Для мерчанта Vipps зазвичай дешевше карткового MDR, але умови розрізняються у PSP (фікс/низький% + збори за віджети/звіти).
Врахуйте операційні витрати: підтримка'pending/expired', диспути, recon і моніторинг SLA.
7) Повернення і диспути
Chargeback як в карт-схемах відсутній. Повернення - нова кредитова операція від мерчанта до платника; допускаються partial refunds.
Терміни - банківські (часто T + 0/T + 1).
Диспути/скарги - за процедурами PSP/банку: зберігайте логи замовлення, підтвердження надання послуги/доставки.
8) Безпека та відповідність
SCA через BankID, device binding і ризик-скоринг банку.
PII-мінімізація: зберігайте тільки необхідні атрибути (телефон/refs), шифруйте PII, обмежуйте доступ (RBAC).
Webhooks: HMAC/nonce, захист від replay, тайм-штампи, дедуп подій.
Відповідність PSD2/GDPR і локальним вимогам (Finanstilsynet).
9) Інтеграція мерчанта
Варіанти
1. Hosted/Embedded від PSP - швидкий старт, App2App/QR/Link «з коробки».
2. Server-to-Server + App2App/QR - власний UX, динамічний QR per-order, тонка обробка помилок.
3. Pay-by-Link/Invoice - інвойс в SMS/email/месенджері з підтвердженням в Vipps.
- API: `createPayment`, `requestToPay`, `refund`, `webhook`, `reconcile`.
- Ідемпотентність ('orderId'+ ключ), експоненціальні ретраї, дедуп подій.
- Recon: daily auto-recon + періодичний full-recon; зберігання UTR/банківської референції.
- SLA-дашборди: конверсія, «pending→success/expired», латентність до зарахування/повернення.
10) Звірка і звітність
Логіруйте: 'paymentId/transactionId','orderId', канал (App2App/QR/Link/POS), телефон платника/alias, статус, сума/валюта, timestamp, UTR.
З PSP/банку: реєстри зарахувань/повернень/корекцій та пізні оновлення статусів.
Налаштуйте алерти по розсинхронах і підвислим'pending'.
11) UX-патерни
Mobile-first: на мобільних - App2App; на десктопі великий динамічний QR з таймером.
Прозорі помилки: ліміт, відмова SCA/BankID, таймаут; безпечний повтор і альтернатива (карта/SEPA/інший A2A).
Квитанція: сума, час,'transactionId', канал, UTR, контакти саппорта.
Термін дії для QR/запитів + зрозумілий сценарій відновлення.
12) Рекуррент і мандати
Використовуйте зв'язку: перший платіж Vipps (SCA) → мандат (AvtaleGiro/OB-mandate).
У мандаті фіксуйте ліміт per debit, періодичність, вікно списання, повідомлення; дайте користувачеві екран управління (pause/cancel/update).
13) Високоризикові вертикалі (включаючи iGaming)
Доступність каналів і ліміти визначаються політиками банку/PSP і локальним правом.
Очікуйте знижені пороги, посилений КУС/моніторинг, можливі hold'и.
Плануйте альтернативні рейки (карти, SEPA, інші PIS) і smart-routing по ризику/каналу/банку.
14) Архітектура «Vipps Gateway»
API-шар (REST/GraphQL) для каси/бекофісу.
Черги подій: статус-івенти → білінг/CRM/аналітика.
Security: vault для секретів, IP-allowlist PSP, сувора валідація redirect-URI, анти-replay токени.
Observability: конверсія по каналах (App2App/QR/Link/POS), частка'pending→expired', час до settlement/повернення.
15) Чек-лист виведення в прод
1. Підключіть Vipps у PSP/банку, виберіть канали (App2App/QR/Link/POS).
2. Реалізуйте'createPayment '/' requestToPay', динамічний QR, екрани помилок/лімітів.
3. Підключіть webhooks, ідемпотентність, ретраї і дедуп подій.
4. Налаштуйте recon (daily + full), зберігання UTR/фін-референцій.
5. Підтримайте partial/full refunds і ODR-процедури.
6. Запустіть SLA-дашборди та алерти (конверсія/латентність/підвислі статуси).
7. Проведіть e2e-тести з основними банками/пристроями та офлайн-точками (якщо актуально).
Картка орієнтирів по лімітах
Per-txn / 24h / 7d: зберігати в конфігу і перевіряти до запуску.
Нові одержувачі/мерчанти: знижені пороги/витримка.
Канали: окремі ліміти для P2P, e-commerce (App2App/QR/Link), POS, інвойсів/платіжних запитів.
Velocity/ризик: антифрод банку може м'яко відхиляти/уповільнювати операції.
Резюме
Для онлайну - App2App + динамічний QR, для офлайну - QR/POS, для простих перекладів - P2P на телефон.
Поділяйте онлайн-підтвердження і фінальний кредит в логіці; будуйте навколо webhooks + recon і partial refunds.
Не фіксуйте суми: ведіть конфіги лімітів по банках/каналах, регулярно актуалізуйте.
Для підписок - зв'язка перший Vipps → мандат з прозорим управлінням і повідомленнями.