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 и локальным правом.
Ожидайте пониженные пороги, усиленный KYC/мониторинг, возможные 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).

Нажимая кнопку, вы соглашаетесь на обработку данных.