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).

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