BLIK Polonia: codici e P2P

1) Cos'è BLIK e dove viene applicato

BLIK è un sistema nazionale polacco di pagamenti A2A integrato nelle applicazioni mobili delle banche. L'utente conferma le transazioni nella propria applicazione bancaria; I soldi si muovono direttamente tra i conti. Gli scenari sono: e-commerce, POS, P2P «per telefono», ATM (prelievo/addebito), fatture di pagamento, biglietti/parcheggio e BLIK Connectless (NFC) per offline.

• Un unico UX tramite applicazioni bancarie (SCA/biometria).
• Codice monouso a 6 cifre (corto) e conferma push senza codice (OneClick/Token/Push).
• P2P per numero di telefono (alias), istantaneamente 24/7.
• QR e offline senza contatto (terminali/NFC), più transazioni nei bancomat.

2) Membri dell'ecosistema

Operatore schema (BLIK/Maght) - Regole, routing, certificazione.
Banche partecipanti: emettitori di applicazioni BLIK (pagatore e destinatario), antifrode e limiti.
Acquirer/PSP: provider per il merchant (Equairing BLIK in linea/offline).
Merchant/provider di servizi: avvia il pagamento, riceve gli stati/fondi.

3) Modalità di pagamento BLIK

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

L'utente nell'applicazione della banca fa clic su «BLIK» per visualizzare il codice a 6 cifre (convalidato da not 2 min).
Inserisce il codice sul sito/biglietteria/bancomat, il telefono riceve una richiesta push e conferma la biometria/PIN.
Il denaro viene addebitato, il merchant ottiene lo status online.

3. 2 BLIK OneClick / Push / Token

Al primo pagamento viene creato un collegamento (token) merchant con il dispositivo/account.
I nuovi acquisti sono confermati da una richiesta push nell'applicazione della banca senza il codice a 6 cifre (più veloce, superiore alla conversione).
Nell'e-commerce, questo è il copione principale.

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

QR dinamico per-order: codifica l'importo e i metadati l'utente sta scansionando la fotocamera dell'applicazione bancaria.
QR statico codificato da VPA/ID del destinatario; la somma viene immessa manualmente (raramente per i merchant).

3. 4 BLIK Contactless (NFC)

Pagamento senza contatto con il telefono su un terminale POS (come le carte), conferma su un'applicazione bancaria.
Adatto per microparti e acquisti quotidiani; funziona su una rete di terminali che supporta BLIK senza contatto.

3. 5 P2P «per telefono»

Il mittente seleziona il contatto dalla rubrica telefonica o inserisce il numero di della conferma.
Il destinatario riceve denaro sul conto relativo al suo numero di telefono - rapidamente e 24/7.

3. 6 ATM - prelievo/incasso di contanti

Cash-out: lo schermo del bancomat introduce un codice BLIK a 6 cifre per la conferma nell'applicazione di distribuzione di contanti.
Cash-in: ricarica il conto tramite bancomat che supportano l'accettazione.

4) Stati tipici

`initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
In offline sono possibili ritardi di conferma; tenete i timeout e ripetete lo stato.

5) Limiti e comportamento delle banche

• Per-trasmissione (per un massimo di un'operazione).
• Per-day/24h/7d (volumi totali/quantità).
• Nuovo destinatario/nuovo merchant - soglie ridotte e/o estrazione.
• Canale/script: limiti separati per P2P, POS, e-commerce, ATM, NFC, QR.
• Velocity/regole di rischio: antifrode banca (frequenza, geo, dispositivo, importo).

6) Tariffe ed economia

Per la commissione Merchant sotto la scheda MDR; la struttura degli incassi dipende da PSP/Equayer e canale (online/POS/QR).
Tenere conto del costo dell'integrazione, del web hook, della riscossione, del supporto dei display e dei ritorni.

7) Restituzioni e display (ODR)

Chargeback è assente in termini di carte. Restituzione - Nuovo prestito di merchant al pagatore (possibilità parziali).
Display - Attraverso i regolamenti PSP/banca e processi ODR (fogli di ordine, assegno, spedizione).

8) Sicurezza e compliance

SCA nell'applicazione banca (biometria/PIN), device bining.
Antifrode bancaria: velocity, nuovi destinatari, controllo degli aliasi, modello di rischio.
Riduzioni PII, crittografia del web hook, HMAC/nonce, registro di controllo.
Conformità ai requisiti locali di pagamento e protezione dei dati.

9) Pratiche UX

Codice vs Push: se possibile, proporre più velocemente e più velocemente la conversione.
QR offline - Usa il QR dinamico per-order per ridurre gli errori, la combinazione perfetta.
Idampotenza: 'orderId' + chiave di idempotenza per ripetizioni sicure.
Ripetizioni/ripristino: con «pending/timeout» mostrate un'alternativa e una ripetizione comprensibili (mappa/metodo diverso).
Ricevuta: importo, data/ora, canale (Code/Push/QR/NFC), ID pagamento/UTR.

10) Opzioni di integrazione per il merchant

1. Hosted/Embedded di PSP - avvio rapido, schermi/reading pronti, states.
2. Server-to-Server + widget è un proprio checkout con elenco di banche, codice, QR, push.
3. POS/SoftPOS - ricezione di BLIK nelle casse/terminali (QR/NFC).
4. Integrazione ATM (per banche/partner) - prelievo/avvento tramite BLIK.

• API: `createPayment`, `confirm`, `refund`, `webhook`, `reconcile`.
• Webhooks con HMAC, retrai e backoff, deduplicazione degli eventi.
• Auto-recon (daily) + full-recon (periodico); Archiviazione UTR/arbitro.
• Tabella di idempotenza e mappa degli stati ('pending→success/expired').

11) Accoppiamento e reporting

Logica «paymentId/transactionId», «orderId», canale (Code/Push/QR/NFC), banca pagante, stato, importo/valuta, timestamp, UTR/giudizio bancario.
I report PSP includono parametri di origine, aggiornamenti tardivi, restituzioni/rimborsi parziali, annullamenti.
Aggiustate gli alert per i disincantesimi e i dashboard della SLA.

12) BLIK in iGaming/verticali ad alto rischio

La disponibilità di BLIK dipende dalle politiche PSP/banche e dal diritto locale.
Attende limiti più severi, un KYC esteso, controlli più elevati del destinatario e possibili hold's.
Tenete i binari alternativi (mappe, SEPA, open-banking PIS) e routing intelligente sul profilo del giocatore.

13) BLIK Connectless (dettagli di implementazione)

Richiede il supporto della banca emittente e dell'infrastruttura terminale.
UX veloce (prova - conferma nell'applicazione), ma i limiti e l'antifrode possono variare da code/QR.
In questo report è possibile assegnare un canale NFC per monitorare la conversione e i guasti.

14) Assegno foglio di output

1. Selezionare PSP/Equyer BLIK (online/POS/QR/NFC), concordare tariffe e SLA.
2. Applica «createPayment» + UX (Code/Push/QR/NFC) e chiari errori/limiti.
3. Collegare webhooks, idimpotenza, timeout e ripetizioni.
4. Attivare i rifunds (partial/full), le procedure ODR e gli script zapport.
5. Configura il recon (daily + full), memorizza le istruzioni UTR/fine.
6. Costruisci il monitoraggio SLA attraverso i canali (Code/Push/QR/NFC), gli alert «pending→expired».
7. Coprire i test end-to-end con banche emettitrici, POS, ATM, piattaforme mobili.

Scheda di riferimento dei limiti

Per-txn/24h/7d: memorizza e controlla prima dell'avvio.
Nuovi destinatari/merchant: soglie ridotte e/o estrazione.
Canali: limiti separati per P2P, e-commerce, POS, ATM, NFC, QR.
Velocity/Risk - L'antifrode della banca può respingere e rallentare le operazioni.

Riepilogo

Per online, scommettere su BLIK OneClick/Push; per l'offline: QR dinamico e Connectless.
Non incanalare gli importi rigidi: utilizzare i configli dei limiti di banca/canale.
Costruisci un'architettura intorno a webhooks + recon, restituzioni parziali e elaborazione nitida'pending/expired '.
Per P2P, basarsi su alias per numero di telefono e mostrare all'utente i rischi e i limiti contestuali.