GH GambleHub

BLIK Польша: коды и P2P

1) Что такое BLIK и где он применяется

BLIK — польская национальная схема A2A-платежей, интегрированная в мобильные приложения банков. Пользователь подтверждает операции в своем банковском приложении; деньги двигаются напрямую между счетами. Сценарии: e-commerce, POS, P2P «на телефон», ATM (снятие/внос), счета к оплате, билеты/парковки, а также BLIK Contactless (NFC) для офлайна.

Ключевые свойства:
  • Единый UX через банковские приложения (SCA/биометрия).
  • 6-значный одноразовый код (короткоживущий) и push-подтверждение без ввода кода (OneClick/Token/Push).
  • P2P по номеру телефона (alias), мгновенно 24/7.
  • QR и бесконтактный офлайн (терминалы/NFC), плюс операции в банкоматах.

2) Участники экосистемы

Оператор схемы (BLIK/свитч): правила, роутинг, сертификация.
Банки-участники: эмитенты приложений BLIK (плательщика и получателя), антифрод и лимиты.
Acquirer/PSP: провайдер для мерчанта (онлайновый/офлайновый эквайринг BLIK).
Мерчант/Провайдер услуг: инициирует платеж, получает статусы/средства.

3) Режимы оплаты BLIK

3.1 BLIK Code (e-commerce/касса/ATM)

Пользователь в приложении банка нажимает «BLIK» → видит 6-значный код (валиден ~2 мин).
Вводит код на сайте/кассе/банкомате → на телефон приходит push-запрос → подтверждает биометрией/PIN.
Деньги списываются, мерчант получает онлайн-статус.

3.2 BLIK OneClick / Push / Token

При первом платеже создается связка (token) мерчанта с устройством/аккаунтом.
Повторные покупки подтверждаются push-запросом в приложении банка без ввода 6-значного кода (быстрее, выше конверсия).
В e-commerce это основной «безкодовй» сценарий.

3.3 BLIK QR (POS/e-commerce)

Динамический QR per-order: кодируется сумма и метаданные; пользователь сканирует камерой банковского приложения → подтверждает в приложении.
Статический QR: кодируется VPA/ID получателя; сумма вводится вручную (редко для мерчантов).

3.4 BLIK Contactless (NFC)

Бесконтактная оплата телефоном на POS-терминале (подобно картам), подтверждение в банковском приложении.
Подходит для микроплатежей и повседневных покупок; работает в сети терминалов, поддерживающих бесконтактный BLIK.

3.5 P2P «на телефон» (превод на номер)

Отправитель выбирает контакт из телефонной книги или вводит номер → сумма → подтверждение.
Получатель получает деньги на счет, связанный с его номером телефона (alias) — быстро и 24/7.

3.6 ATM: снятие/внос наличных

Cash-out: на экране банкомата вводится 6-значный BLIK-код → подтверждение в приложении → выдача наличных.
Cash-in: пополнение счета через банкоматы, поддерживающие прием.

4) Типовые статусы

`initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
В офлайне возможны задержки подтверждения; держите таймауты и повтор статуса.

5) Лимиты и поведение банков

Единого «схемного» потолка нет — лимиты задаются банками и зависят от уровня KYC, истории, устройства и сценария:
  • Per-transaction (максимум на одну операцию).
  • Per-day / 24h / 7d (суммарные объемы/количество).
  • Новый получатель/новый мерчант — сниженные пороги и/или выдержка.
  • Канал/сценарий: отдельные лимиты на P2P, POS, e-commerce, ATM, NFC, QR.
  • Velocity/риск-правила: антифрод банка (частота, гео, устройство, сумма).
💡 Практика: не хардкодьте цифры; ведите справочник лимитов по банкам и сценариям, обновляйте его; в UX показывайте понятные причины отказа и альтернативы (разбить платеж, другой метод, повтор позже).

6) Тарифы и экономика

Для мерчанта комиссии ниже картового MDR; структура сборов зависит от PSP/эквайера и канала (онлайн/POS/QR).
Учитывайте стоимость интеграции, веб-хуков, reconcilliation, поддержку диспутов и возвратов.

7) Возвраты и диспуты (ODR)

Chargeback в карточном смысле отсутствует. Возврат — новая кредитовая операция мерчанта плательщику (возможны частичные).
Диспуты — через регламенты PSP/банка и ODR-процессы (логи заказа, чек, доставка).

8) Безопасность и комплаенс

SCA в приложении банка (биометрия/PIN), device binding.
Банковский антифрод: velocity, новые получатели, проверка алиасов, модель риска.
PII-минимизация, шифрование веб-хуков, HMAC/nonce, журнал аудита.
Соответствие локальным требованиям платежных услуг и защите данных.

9) UX-практики

Код vs Push: по возможности предлагайте OneClick/Push — быстрее и выше конверсия.
QR в офлайне: используйте динамический QR per-order → меньше ошибок, идеальная сверка.
Идемпотентность: `orderId` + ключ идемпотентности для безопасных повторов.
Повторы/восстановление: при `pending/timeout` показывайте понятный повтор и альтернативу (карта/другой метод).
Квитанция: сумма, дата/время, канал (Code/Push/QR/NFC), идентификатор платежа/UTR.

10) Интеграционные варианты для мерчанта

1. Hosted/Embedded от PSP — быстрый старт, готовые экраны/редиректы, статусы.
2. Server-to-Server + виджет — собственный checkout со списком банков, кодом, QR, push.
3. POS/SoftPOS — прием BLIK на кассах/терминалах (QR/NFC).
4. ATM-интеграция (для банков/партнеров) — снятие/внос через BLIK.

Обязательные компоненты бэкенда:
  • API: `createPayment`, `confirm`, `refund`, `webhook`, `reconcile`.
  • Webhooks с HMAC, ретраи и backoff, дедупликация событий.
  • Auto-recon (daily) + full-recon (периодический); хранение UTR/референсов.
  • Таблица идемпотентности и карта статусов (`pending→success/expired`).

11) Сверка и отчетность

Логируйте: `paymentId/transactionId`, `orderId`, канал (Code/Push/QR/NFC), банк плательщика, статус, сумму/валюту, timestamp, UTR/банковскую референцию.
В PSP-отчетах: исходные параметры, поздние обновления, возвраты/частичные возвраты, отмены.
Настройте алерты по рассинхронам и дэшборды SLA.

12) BLIK в iGaming/высокорисковых вертикалях

Доступность BLIK зависит от политики PSP/банков и локального права.
Ожидайте ужесточенные лимиты, расширенный KYC, усиленные проверки получателя и возможные hold’ы.
Держите альтернативные рельсы (карты, SEPA, open-banking PIS) и умную маршрутизацию по профилю игрока.

13) BLIK Contactless (детали внедрения)

Требует поддержки со стороны банка-эмитента и терминальной инфраструктуры.
UX быстрый (поднеси — подтверди в приложении), но лимиты и антифрод могут отличаться от code/QR.
В отчетности выделяйте канал NFC для мониторинга конверсии и отказов.

14) Чек-лист вывода в прод

1. Выберите PSP/эквайера BLIK (онлайн/POS/QR/NFC), согласуйте тарифы и SLA.
2. Реализуйте `createPayment` + UX (Code/Push/QR/NFC) и понятные ошибки/лимиты.
3. Подключите webhooks, идемпотентность, таймауты и повторы.
4. Включите refunds (partial/full), процедуры ODR и саппорт-скрипты.
5. Настройте recon (daily+full), хранение UTR/фин-референций.
6. Постройте мониторинг SLA по каналам (Code/Push/QR/NFC), алерты `pending→expired`.
7. Покройте end-to-end тестами банки-эмитенты, POS, ATM, мобильные платформы.

Карточка ориентиров по лимитам

💡 Фактические пороги задают банки и могут отличаться по сценариям.

Per-txn / 24h / 7d: хранить в конфиге и проверять до запуска.
Новые получатели/мерчанты: сниженные пороги и/или выдержка.
Каналы: отдельные лимиты для P2P, e-commerce, POS, ATM, NFC, QR.
Velocity/риск: антифрод банка может мягко отклонять/замедлять операции.

Резюме

Для онлайна делайте ставку на BLIK OneClick/Push; для офлайна — динамический QR и Contactless.
Не вшивайте жесткие суммы — используйте конфиги лимитов по банкам/каналам.
Архитектуру стройте вокруг webhooks + recon, частичных возвратов и четкой обработки `pending/expired`.
Для P2P опирайтесь на alias по номеру телефона и показывайте пользователю контекстные риски и лимиты.

Contact

Свяжитесь с нами

Обращайтесь по любым вопросам или за поддержкой.Мы всегда готовы помочь!

Telegram
@Gamble_GC
Начать интеграцию

Email — обязателен. Telegram или WhatsApp — по желанию.

Ваше имя необязательно
Email необязательно
Тема необязательно
Сообщение необязательно
Telegram необязательно
@
Если укажете Telegram — мы ответим и там, в дополнение к Email.
WhatsApp необязательно
Формат: +код страны и номер (например, +380XXXXXXXXX).

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