BLIK Poland: codes and P2P

1) What is BLIK and where is it applied

BLIK is the Polish national A2A payment scheme integrated into banks' mobile applications. The user confirms the transactions in his banking application; money moves directly between accounts. Scenarios: e-commerce, POS, P2P "on the phone," ATM (withdrawal/deposit), invoices for payment, tickets/parking, as well as BLIK Contactless (NFC) for offline.

• Single UX via banking applications (SCA/biometrics).
• 6-digit one-time code (short-lived) and push confirmation without entering a code (OneClick/Token/Push).
• P2P by phone number (alias), instantly 24/7.
• QR and contactless offline (terminals/NFC), plus ATM operations.

2) Ecosystem participants

Scheme operator (BLIK/switch): rules, routing, certification.
Participating banks: issuers of BLIK applications (payer and recipient), anti-fraud and limits.
Acquirer/PSP: provider for merchant (online/offline acquiring BLIK).
Merchant/Service Provider: initiates payment, receives statuses/funds.

3) BLIK payment modes

3. 1 BLIK Code (e-commerce/cash desk/ATM)

The user in the bank application presses "BLIK" → sees a 6-digit code (valid ~ 2 minutes).
Enters the code on the site/cash register/ATM → a push request comes to the phone → confirms with biometrics/PIN.
The money is debited, the merchant receives online status.

3. 2 BLIK OneClick / Push / Token

The first payment creates a bundle (token) of merchant with a device/account.
Repeat purchases are confirmed by a push request in the bank's application without entering a 6-digit code (faster, higher conversion).
In e-commerce, this is the main "codeless" scenario.

3. 3 BLIK QR (POS/e-commerce)

Dynamic QR per-order: the sum and metadata are encoded; the user scans the banking application with the camera → confirms it in the application.
Static QR: encoded by the recipient's VPA/ID; the amount is entered manually (rare for merchants).

3. 4 BLIK Contactless (NFC)

Contactless payment by phone at the POS terminal (like cards), confirmation in the banking application.
Suitable for micropayments and everyday purchases; works in a network of terminals that support contactless BLIK.

3. 5 P2P "to phone" (transfer to number)

The sender selects a contact from the phone book or enters a number → amount → confirmation.
The recipient receives the money in an account linked to their phone number (alias) - fast and 24/7.

3. 6 ATM cash withdrawals/withdrawals

Cash-out: a 6-digit BLIK code is entered on the ATM screen → confirmation in the application → cash withdrawal.
Cash-in: Top-up through ATMs that support acceptance.

4) Typical statuses

`initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
Confirmation delays are possible offline; keep timeouts and status redo.

5) Limits and behavior of banks

• Per-transaction (maximum per operation).
• Per-day/24h/7d (total volumes/quantity).
• New receiver/new merchant - reduced thresholds and/or shutter speed.
• Channel/scenario: separate limits on P2P, POS, e-commerce, ATM, NFC, QR.
• Velocity/risk rules: anti-fraud bank (frequency, geo, device, amount).

6) Tariffs and economics

For merchant commission below the card MDR; fee structure depends on PSP/acquirer and channel (online/POS/QR).
Consider the cost of integration, web hooks, reconciliation, support for disputes and returns.

7) Returns and Disputes (ODR)

Chargeback is absent in the card sense. Return - a new credit transaction of the merchant to the payer (partial ones are possible).
Disputes - through PSP/bank regulations and ODR processes (order logs, check, delivery).

8) Safety and compliance

SCA in the bank application (biometrics/PIN), device binding.
Banking anti-fraud: velocity, new recipients, verification of aliases, risk model.
PII minimization, web hook encryption, HMAC/nonce, audit log.
Meet local payment and data protection requirements.

9) UX practices

Code vs Push: If possible, offer OneClick/Push - faster and higher conversion.
QR offline: use dynamic QR per-order → fewer errors, perfect reconciliation.
Idempotence: 'orderId' + idempotence key for safe repeats.
Redo/Restore: When 'pending/timeout', show clear redo and alternative (map/other method).
Receipt: amount, date/time, channel (Code/Push/QR/NFC), payment ID/UTR.

10) Integration options for merchant

1. Hosted/Embedded from PSP - fast start, ready-made screens/redirects, statuses.
2. Server-to-Server + widget - own checkout with a list of banks, code, QR, push.
3. POS/SoftPOS - reception of BLIK at cash registers/terminals (QR/NFC).
4. ATM integration (for banks/partners) - withdrawal/entry via BLIK.

• API: `createPayment`, `confirm`, `refund`, `webhook`, `reconcile`.
• Webhooks with HMAC, retrays and backoff, event deduplication.
• Auto-recon (daily) + full-recon (periodic); UTR/reference storage.
• Idempotency table and status map ('pending→success/expired').

11) Reconciliation and Reporting

Log: 'paymentId/transactionId', 'orderId', channel (Code/Push/QR/NFC), payer's bank, status, amount/currency, timestamp, UTR/bank reference.
In PSP reports: initial parameters, late updates, returns/partial returns, cancellations.
Set up desynchronized alerts and SLA dashboards.

12) BLIK in iGaming/high-risk verticals

BLIK availability depends on PSP/bank policy and local law.
Expect tightened limits, expanded KYC, increased recipient checks and possible holds.
Keep alternative rails (cards, SEPA, open-banking PIS) and smart routing by player profile.

13) BLIK Contactless (implementation details)

Requires support from the issuing bank and terminal infrastructure.
UX is fast (bring it up - confirm it in the application), but limits and anti-fraud may differ from code/QR.
In reporting, allocate an NFC channel to monitor conversions and failures.

14) Output checklist

1. Select PSP/acquirer BLIK (online/POS/QR/NFC), agree on tariffs and SLAs.
2. Implement 'createPayment' + UX (Code/Push/QR/NFC) and understandable errors/limits.
3. Connect webhooks, idempotency, timeouts and replays.
4. Include refunds (partial/full), ODR procedures, and support scripts.
5. Set up recon (daily + full), UTR/fin references storage.
6. Build SLA monitoring by channels (Code/Push/QR/NFC), alerts' pending→expired '.
7. Cover end-to-end tests with issuing banks, POS, ATM, mobile platforms.

Limit Reference Card

Per-txn/24h/7d: store in config and check before starting.
New recipients/merchants: reduced thresholds and/or exposure.
Channels: separate limits for P2P, e-commerce, POS, ATM, NFC, QR.
Velocity/risk: Bank antifraud can gently deflect/slow down operations.

Summary

For online, bet on BLIK OneClick/Push; for offline - dynamic QR and Contactless.
Do not sew hard amounts - use limit configs by bank/channel.
Build the architecture around webhooks + recon, partial returns and clear handling of'pending/expired'.
For P2P, rely on alias by phone number and show the user contextual risks and limits.