GH GambleHub

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).
💡 Práctica: no hardcode los números; Mantenga una guía de límites de bancos y escenarios, actualícela; en UX, muestre las razones claras del rechazo y las alternativas (dividir el pago, otro método, repetir más tarde).

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.

Componentes de respaldo obligatorios:
  • 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

💡 Los umbrales reales establecen los bancos y pueden variar según los escenarios.

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.

Contact

Póngase en contacto

Escríbanos ante cualquier duda o necesidad de soporte.¡Siempre estamos listos para ayudarle!

Telegram
@Gamble_GC
Iniciar integración

El Email es obligatorio. Telegram o WhatsApp — opcionales.

Su nombre opcional
Email opcional
Asunto opcional
Mensaje opcional
Telegram opcional
@
Si indica Telegram, también le responderemos allí además del Email.
WhatsApp opcional
Formato: +código de país y número (por ejemplo, +34XXXXXXXXX).

Al hacer clic en el botón, usted acepta el tratamiento de sus datos.