GH GambleHub

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.
💡 Практика: не хардкодьте цифри. Ведіть довідник лімітів по банках/каналах, регулярно оновлюйте і в UI показуйте «ліміт банку/каналу» з варіантами (розбити платіж, інший метод, повтор пізніше).

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-тести з основними банками/пристроями та офлайн-точками (якщо актуально).

Картка орієнтирів по лімітах

💡 Реальні пороги задають банк/PSP і відрізняються за сценаріями.

Per-txn / 24h / 7d: зберігати в конфігу і перевіряти до запуску.
Нові одержувачі/мерчанти: знижені пороги/витримка.
Канали: окремі ліміти для P2P, e-commerce (App2App/QR/Link), POS, інвойсів/платіжних запитів.
Velocity/ризик: антифрод банку може м'яко відхиляти/уповільнювати операції.

Резюме

Для онлайну - App2App + динамічний QR, для офлайну - QR/POS, для простих перекладів - P2P на телефон.
Поділяйте онлайн-підтвердження і фінальний кредит в логіці; будуйте навколо webhooks + recon і partial refunds.
Не фіксуйте суми: ведіть конфіги лімітів по банках/каналах, регулярно актуалізуйте.
Для підписок - зв'язка перший Vipps → мандат з прозорим управлінням і повідомленнями.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Telegram
@Gamble_GC
Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.