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/ризик-правила: антифрод банку (частота, гео, пристрій, сума).
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 за номером телефону і показуйте користувачеві контекстні ризики і ліміти.