BLIK Pologne : codes et P2P

1) Qu'est-ce que le BLIK et où il s'applique

BLIK est un système de paiement national polonais A2A intégré dans les applications mobiles des banques. L'utilisateur confirme les transactions dans son application bancaire ; l'argent se déplace directement entre les comptes. Scénarios : e-commerce, POS, P2P « par téléphone », ATM (retrait/pénétration), factures à payer, billets/parkings, et BLIK Contactless (NFC) pour offline.

• UX unique via des applications bancaires (SCA/biométrie).
• Code à 6 chiffres (à courte durée de vie) et confirmation push sans entrée de code (OneClick/Token/Push).
• P2P par numéro de téléphone (alias), instantanément 24/7.
• QR et hors ligne sans contact (terminaux/NFC), plus les opérations dans les guichets automatiques.

2) Acteurs de l'écosystème

Opérateur de circuit (BLIK/pull) : règles, itinérance, certification.
Banques participantes : émetteurs de demandes BLIK (payeur et bénéficiaire), antifrod et limites.
Acquirer/PSP : fournisseur pour le merchant (BLIK online/offline acquering).
Merchant/Prestataire : Initie le paiement, reçoit les statuts/fonds.

3) Modes de paiement BLIK

3. 1 code BLIK (e-commerce/caisse/ATM)

L'utilisateur de l'application de la banque appuie sur « BLIK » → voit le code à 6 chiffres (validé ~ 2 min).
Entre le code sur le site/caisse/guichet automatique → une demande push arrive sur le téléphone → confirme la biométrie/PIN.
L'argent est débité, le merchant obtient le statut en ligne.

3. 2 BLIK OneClick / Push / Token

Le premier paiement crée un lien (token) du merchant avec le périphérique/compte.
Les achats répétés sont confirmés par une demande push dans l'application de la banque sans entrer de code à 6 chiffres (plus rapide, plus de conversion).
Dans le commerce électronique, c'est le scénario principal.

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

QR dynamique per-order : la somme et les métadonnées sont codées ; l'utilisateur scanne l'application bancaire avec la caméra → confirme dans l'application.
QR statique : Codé par VPA/ID du destinataire ; la somme est introduite manuellement (rarement pour les merchants).

3. 4 BLIK Contactless (NFC)

Paiement sans contact par téléphone sur un terminal POS (comme les cartes), confirmation dans une application bancaire.
Convient pour les micropaiements et les achats quotidiens ; fonctionne sur un réseau de terminaux prenant en charge le BLIK sans contact.

3. 5 P2P « par téléphone » (préau par numéro)

L'expéditeur sélectionne un contact dans l'annuaire téléphonique ou entre le numéro → le montant → la confirmation.
Le destinataire reçoit de l'argent sur le compte associé à son numéro de téléphone (alias) - rapidement et 24/7.

3. 6 ATM : retrait/injection d'argent

Cash-out : sur l'écran du guichet automatique, un code BLIK à 6 chiffres → une confirmation dans l'application → la délivrance d'argent.
Cash-in : réapprovisionnement de la facture via les guichets automatiques qui soutiennent la réception.

4) Statuts types

`initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
Des retards de confirmation sont possibles en ligne ; Gardez le temps et le statut de répétition.

5) Limites et comportement des banques

• Per-transaction (au maximum par opération).
• Per-day/24h/7d (volumes/quantités totaux).
• Nouveau destinataire/nouveau merchant - seuils réduits et/ou vitesse d'obturation.
• Canal/script : limites séparées sur P2P, POS, e-commerce, ATM, NFC, QR.
• Velocity/règles de risque : antifrod de la banque (fréquence, géo, appareil, somme).

6) Tarifs et économie

Pour le merchant, les commissions sont inférieures à la carte MDR ; la structure des redevances dépend du PSP/acquéreur et du canal (en ligne/POS/QR).
Tenez compte du coût de l'intégration, des hooks Web, de la reconnaissance, de la prise en charge des disputes et des retours.

7) Retours et disputes (ODR)

Il n'y a pas de chargeback dans le sens de la carte. Retour - nouvelle opération de crédit du merchant au payeur (peut-être partielle).
Les disputes - à travers les règlements PSP/banque et les processus ODR (logs de commande, chèque, livraison).

8) Sécurité et conformité

SCA dans l'application de la banque (biométrie/PIN), binding d'appareils.
Antifrod bancaire : velocity, nouveaux destinataires, vérification des alias, modèle de risque.
Minimisation des PII, cryptage Web, HMAC/nonce, journal d'audit.
Conformité aux exigences locales en matière de services de paiement et de protection des données.

9) Pratiques UX

Code vs Push : si possible, proposez une conversion OneClick/Push - plus rapide et plus élevée.
QR hors ligne : utilisez le QR dynamique per-order → moins d'erreurs, un rapprochement parfait.
Idempotence : 'orderId' + clé d'idempotence pour les répétitions sécurisées.
Répétitions/restauration : sous 'pending/timeout', montrez une répétition et une alternative compréhensibles (carte/autre méthode).
Reçu : montant, date/heure, canal (Code/Push/QR/NFC), ID de paiement/UTR.

10) Options d'intégration pour le merchant

1. Hosted/Embedded de PSP - démarrage rapide, écrans prêts/radiés, statuts.
2. Server-to-Server + widget est votre propre checkout avec une liste de banques, code, QR, push.
3. POS/SoftPOS - Réception de BLIK aux guichets/terminaux (QR/NFC).
4. Intégration ATM (pour les banques/partenaires) - retrait/pénétration via BLIK.

• API: `createPayment`, `confirm`, `refund`, `webhook`, `reconcile`.
• Webhooks avec HMAC, retraits et backoff, déduplication d'événements.
• Auto-recon (daily) + full-recon (périodique) ; stockage des UTR/référents.
• Tableau d'idempotence et carte des statuts ('pending→success/expired').

11) Rapprochement et établissement de rapports

Loger : 'paymentId/transactionId', 'orderId', canal (Code/Push/QR/NFC), banque du payeur, statut, montant/devise, timestamp, UTR/référence bancaire.
Dans les rapports PSP : paramètres d'origine, mises à jour tardives, retours/retours partiels, annulations.
Configurez les alertes par dissynchrones et dashboards SLA.

12) BLIK dans iGaming/Verticales à haut risque

L'accessibilité de BLIK dépend de la politique PSP/banques et du droit local.
Attendez-vous à des limites serrées, à des KYC étendues, à des vérifications renforcées du destinataire et à des hold's possibles.
Gardez des rails alternatifs (cartes, SEPA, PIS open banking) et un routage intelligent par profil de joueur.

13) Contact BLIK (détails de mise en œuvre)

Nécessite le soutien de la banque émettrice et de l'infrastructure terminal.
UX est rapide (sous - confirmez dans l'application), mais les limites et l'antifrode peuvent différer du code/QR.
Dans les rapports, allouer un canal NFC pour surveiller les conversions et les pannes.

14) Chèque-liste de sortie dans la prod

1. Choisissez le PSP/acquéreur BLIK (en ligne/POS/QR/NFC), acceptez les tarifs et SLA.
2. Implémentez 'createPayment' + UX (Code/Push/QR/NFC) et les erreurs/limites compréhensibles.
3. Connectez webhooks, idempotence, temporisation et répétitions.
4. Incluez les refunds (partial/full), les procédures ODR et les scripts sappport.
5. Configurez recon (daily + full), stockage UTR/fin-références.
6. Construisez une surveillance SLA sur les canaux (Code/Push/QR/NFC), alerte 'pending→expired'.
7. Couvrez les banques émettrices, POS, ATM, plateformes mobiles avec des tests de bout en bout.

Carte de référence par limite

Per-txn/24h/7d : stocker dans un configh et vérifier avant le démarrage.
Nouveaux destinataires/merchants : seuils réduits et/ou vitesse d'obturation.
Canaux : limites séparées pour P2P, e-commerce, POS, ATM, NFC, QR.
Velocity/risque : l'antifrod de la banque peut légèrement rejeter/ralentir les opérations.

Résumé

Pour en ligne, pariez sur BLIK OneClick/Push ; pour offline - QR dynamique et Contactless.
Ne mettez pas les montants durs - utilisez les limites des banques/canaux.
Construisez votre architecture autour de webhooks + recon, de retours partiels et d'un traitement clair 'pending/expired'.
Pour P2P, comptez sur alias par numéro de téléphone et montrez à l'utilisateur les risques et limites contextuels.