BLIK Polonia: códigos y P2P
1) Qué es BLIK y dónde se aplica
BLIK es un esquema de pago nacional polaco A2A integrado en las aplicaciones móviles de los bancos. El usuario confirma las transacciones en su aplicación bancaria; el dinero se mueve directamente entre las cuentas. Escenarios: e-commerce, POS, P2P «por teléfono», ATM (retiros/entradas), facturas de pago, entradas/estacionamientos, así como BLIK Contactless (NFC) para offline.
Propiedades clave:- UX unificado a través de aplicaciones bancarias (SCA/biometría).
- Código de un solo uso de 6 dígitos (de vida corta) y confirmación de inserción sin entrada de código (OneClick/Token/Push).
- P2P por número de teléfono (alias), al instante 24/7.
- QR y sin contacto (terminales/NFC), además de operaciones en cajeros automáticos.
2) Participantes del ecosistema
Operador de circuitos (BLIK/switch): reglas, routing, certificación.
Bancos participantes: emisores de aplicaciones BLIK (pagador y destinatario), antifraude y límites.
Acquirer/PSP: proveedor de merchant (acquirer BLIK online/offline).
Merchant/Proveedor de servicios: inicia el pago, recibe los estados/fondos.
3) Modos de pago BLIK
3. 1 Código BLIK (e-commerce/taquilla/ATM)
El usuario en la aplicación del banco hace clic en «BLIK» → ve un código de 6 dígitos (válido ~ 2 min).
Introduce el código en el sitio web/cajero/cajero automático → la solicitud de inserción llega al teléfono → confirma por biometría/PIN.
El dinero es cargado, el merchant recibe el estado en línea.
3. 2 BLIK OneClick / Push / Token
La primera vez que se paga, se crea un paquete (token) de merchant con el dispositivo/cuenta.
Las compras repetidas se confirman mediante una solicitud push en la aplicación del banco sin introducir un código de 6 dígitos (más rápido, por encima de la conversión).
En e-commerce, este es el escenario principal «sin código».
3. 3 BLIK QR (POS/e-commerce)
QR dinámico por orden: se codifica la suma y los metadatos; el usuario escanea la cámara de la aplicación bancaria → la confirma en la aplicación.
QR estático: codificado por el VPA/ID del destinatario; la cantidad se introduce manualmente (raramente para los merchantes).
3. 4 BLIK Contactless (NFC)
Pago sin contacto por teléfono en una terminal POS (similar a las tarjetas), confirmación en una aplicación bancaria.
Adecuado para micropagos y compras diarias; funciona en una red de terminales que soportan BLIK sin contacto.
3. 5 P2P «por teléfono» (predeterminado por número)
El remitente selecciona un contacto de la libreta de teléfonos o introduce un número → importe → confirmación.
El destinatario recibe dinero en una cuenta asociada a su número de teléfono (alias) - rápido y 24/7.
3. 6 ATM: retiro/depósito de efectivo
Cash-out: en la pantalla del cajero automático se introduce un código BLIK de 6 dígitos → confirmación en la aplicación → emisión de efectivo.
Cash-in: deposita fondos a través de cajeros automáticos que apoyan la recepción.
4) Estados estándar
`initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
Es posible que haya demoras en la confirmación fuera de línea; mantenga los temporizadores y la repetición del estado.
5) Límites y comportamiento de los bancos
No hay un tope único de «esquema» - los límites son establecidos por los bancos y dependen del nivel de KYC, el historial, el dispositivo y el escenario:- Per-transaction (máximo por operación).
- Per-day/24h/7d (volúmenes totales/cantidad).
- Nuevo receptor/nuevo merchant: umbrales reducidos y/o velocidad de obturación.
- Canal/script: límites individuales en P2P, POS, e-commerce, ATM, NFC, QR.
- Velocity/reglas de riesgo: antifraude del banco (frecuencia, geo, dispositivo, suma).
6) Tarifas y economía
Para el merchant, la comisión está debajo del MDR de la tarjeta; la estructura de tarifas depende del PSP/ecuador y del canal (en línea/POS/QR).
Tenga en cuenta el costo de integración, ganchos web, reconcilliation, soporte de Disputs y reembolsos.
7) Devoluciones y Dispouts (ODR)
Chargeback está ausente en el sentido de la tarjeta. Devoluciones - nueva operación de préstamo de merchant al pagador (posible parcial).
Disputs - a través de regulaciones PSP/banco y procesos ODR (registros de pedidos, cheque, entrega).
8) Seguridad y cumplimiento
SCA en la aplicación del banco (biometría/PIN), device binding.
Antifraude bancario: velocity, nuevos destinatarios, validación de alias, modelo de riesgo.
Minimización PII, cifrado de ganchos web, HMAC/nonce, registro de auditoría.
Cumple con los requisitos locales de servicios de pago y protección de datos.
9) Prácticas UX
Código vs Push: ofrezca OneClick/Push siempre que sea posible - conversión más rápida y más alta.
QR fuera de línea: use QR dinámico por orden → menos errores, la conciliación perfecta.
Idempotencia: 'orderId' + clave de idempotencia para repeticiones seguras.
Repeticiones/restauraciones: cuando 'pending/timeout' muestre una repetición y una alternativa comprensibles (mapa/otro método).
Recibo: cantidad, fecha/hora, canal (Code/Push/QR/NFC), ID de pago/UTR.
10) Opciones de integración para merchant
1. Hosted/Embedded de PSP: inicio rápido, pantallas/redirecciones terminadas, estados.
2. Server-to-Server + widget - su propio checkout con una lista de bancos, código, QR, inserción.
3. POS/SoftPOS - Recepción de BLIK en cajeros/terminales (QR/NFC).
4. Integración ATM (para bancos/socios) - retirada/cobro a través de BLIK.
- API: `createPayment`, `confirm`, `refund`, `webhook`, `reconcile`.
- Webhooks con HMAC, retraídas y backoff, deduplicación de eventos.
- Auto-recon (diario) + full-recon (periódico); Almacenamiento de UTR/referencias.
- Tabla de idempotencia y mapa de estados ('pending→success/expired').
11) Conciliación y presentación de informes
Lógica: 'paymentId/transactionId', 'orderId', canal (Code/Push/QR/NFC), banco del pagador, estado, cantidad/moneda, timestamp, UTR/referencia bancaria.
En los informes PSP: parámetros originales, actualizaciones tardías, devoluciones/devoluciones parciales, cancelaciones.
Personalice las alertas de los rassincrones y los dashboards SLA.
12) BLIK en iGaming/verticales de alto riesgo
La disponibilidad de BLIK depende de la política de PSP/bancos y de la ley local.
Espere límites más estrictos, KYC ampliado, comprobaciones de destinatario reforzado y posibles hold's.
Mantenga raíles alternativos (cartas, SEPA, PIS de banca abierta) y enrutamiento inteligente a través del perfil del jugador.
13) BLIK Contactless (detalles de la implementación)
Requiere el apoyo del banco emisor y de la infraestructura terminal.
UX es rápido (subnets - confirme en la aplicación), pero los límites y los antifraude pueden diferir del code/QR.
En los informes, resalte el canal NFC para supervisar las conversiones y las fallas.
14) Check-list de la salida en el prod
1. Seleccione el PSP/ecuador de BLIK (online/POS/QR/NFC), acuerde tarifas y SLA.
2. Implemente 'createPayment' + UX (Code/Push/QR/NFC) y errores/límites claros.
3. Conecte webhooks, idempotencia, temporizadores y repeticiones.
4. Habilite los refundidos (parcial/full), los procedimientos ODR y los scripts de sapport.
5. Configure recon (daily + full), almacenamiento de referencias UTR/fin.
6. Construya el monitoreo de SLA a través de canales (Code/Push/QR/NFC), alertas 'pending→expired'.
7. Cubre las pruebas end-to-end con bancos emisores, POS, ATM, plataformas móviles.
Tarjeta de referencia de límites
Per-txn/24h/7d: almacenar en la configuración y comprobar antes del inicio.
Nuevos destinatarios/merchantes: umbrales reducidos y/o extracto.
Canales: límites individuales para P2P, e-commerce, POS, ATM, NFC, QR.
Velocity/riesgo: el antifraude del banco puede desviar/ralentizar suavemente las operaciones.
Resumen
Para online, apuesta por BLIK OneClick/Push; para offline: QR dinámico y Contactless.
No coser cantidades rígidas - use los límites de confianza en los bancos/canales.
La arquitectura se construye alrededor de webhooks + recon, devoluciones parciales y procesamiento claro 'pending/expired'.
Para P2P, confía en alias por número de teléfono y muestra al usuario los riesgos y límites contextuales.