BLIK Polônia: códigos e P2P

1) O que é o BLIK e onde é aplicado

BLIK é um sistema nacional polonês de pagamentos A2A integrado a aplicativos móveis de bancos. O usuário confirma as transações em seu aplicativo bancário; O dinheiro mexe diretamente entre as contas. Cenários: e-commerce, POS, P2P «por telefone», ATM (retirada/entrada), contas de pagamento, bilhetes/estacionamento e BLIK Contactless (NFC) para offline.

• UX único através de aplicativos bancários (SCA/biometria).
• Código descartável de 6 dígitos (curto) e confirmação push sem inserção de código (OneClick/Token/Push).
• P2P pelo número de telefone (alias), instantaneamente 24/7.
• QR e offline sem contato (terminais/NFC), além de transações em multibanco.

2) Membros do ecossistema

Operador de esquema (BLIK/swich): regras, roteamento, certificação.
Bancos participantes: emissores de aplicativos BLIK (pagador e destinatário), antifrode e limites.
Aquirer/PSP: Provedor de merchant (online/offline BLIK).
Merchant/Provedor de Serviços: inicia o pagamento, recebe estatais/fundos.

3) Modos de pagamento BLIK

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

O usuário no aplicativo do banco clica em «BLIK» → vê um código de 6 dígitos (validado por £2 min).
Digite o código no site/caixa/caixa → o telefone recebe um pedido push → confirma a biometria/PIN.
O dinheiro é descontado, o merchant recebe o status online.

3. 2 BLIK OneClick / Push / Token

O primeiro pagamento cria uma ligação de merchant com o dispositivo/conta.
As compras repetidas são confirmadas por um pedido push no aplicativo do banco sem a entrada de um código de 6 dígitos (mais rápido, superior à conversão).
No e-commerce, este é o principal cenário «sem código».

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

QR dinâmico para-order: soma codificada e metadados; o usuário analisa a câmera do aplicativo bancário → confirma no aplicativo.
QR estático: codificado VPA/ID do destinatário; a quantia é introduzida manualmente (raramente para merçantes).

3. 4 BLIK Contactless (NFC)

Pagamento de telefone sem contato no terminal POS (como cartões), confirmação no aplicativo bancário.
Adequado para microalgas e compras diárias; funciona em uma rede de terminais sem contato.

3. 5 P2P «por telefone» (refino por quarto)

O remetente seleciona o contato do caderno ou digita o número → o valor → a confirmação.
O destinatário recebe o dinheiro na conta referente ao seu número de telefone (alias) - rápido e 24/7.

3. 6 ATM: retirada/entrada em dinheiro

Cash-out: A tela do multibanco introduz um código BLIK de 6 dígitos → uma confirmação no aplicativo → emissão de dinheiro.
Cash-in: Repor a conta através de multibanco que suporta a recepção.

4) Estatais típicas

`initiated` → `pending` → `success` / `failed` / `canceled` / `expired`.
No offline, pode haver atrasos na confirmação; mantenha o tempo e a repetição de status.

5) Limites e comportamento dos bancos

• Por transferência (no máximo, uma operação).
• Per-day/24h/7d (total/quantidade).
• Novo destinatário/novo merchant - liminares reduzidos e/ou extrato.
• Canal/cenário: limites individuais para P2P, POS, e-commerce, ATM, NFC, QR.
• Velocity/regras de risco: banco antifrode (frequência, geo, dispositivo, soma).

6) Tarifas e economia

Para uma comissão Merchant inferior a um MDR de cartão; a estrutura de taxas depende do PSP/Equeyer e do canal (online/POS/QR).
Leve em conta o custo da integração, do webhooks, da reconciação, do suporte a dispensas e retornos.

7) Devoluções e displays (ODR)

Não há nenhuma Marceback no sentido de cartas. A devolução é uma nova operação de merchant para o pagador (pode ser parcial).
Displays - através de regulamentos PSP/banco e processos ODR (logs de encomenda, cheque, entrega).

8) Segurança e Complacência

SCA no aplicativo do banco (biometria/PIN), device binding.
Antifrode bancário: velocity, novos destinatários, verificação de aliase, modelo de risco.
PII Minimização, criptografia da Web Hook, HMAC/nonce, registo de auditoria.
Conformidade com os requisitos locais de serviços de pagamento e proteção de dados.

9) Práticas UX

Código vs Push: Se possível, ofereça OneClick/Push mais rápido e superior à conversão.
QR em offline: Use QR per-order dinâmico, menos erros, perfeito encurtamento.
Idempotidade: 'orderId' + chave de idempotação para repetições seguras.
Repetições/recuperação: Ao 'pending/timeout', mostre uma repetição clara e uma alternativa (mapa/outro método).
Recibo: valor, data/hora, canal (Código/Push/QR/NFC), ID de pagamento/UTR.

10) Opções de integração para o merchant

1. Hosted/Embedded de PSP - início rápido, telas prontas/redirectos, estatais.
2. O Server-to-Server + widget é um check-out próprio com lista de bancos, código, QR, push.
3. POS/SoftPOS - Recepção do BLIK nas bilheterias/terminais (QR/NFC).
4. Integração ATM (para bancos/parceiros) - retirada/entrada via BLIK.

• API: `createPayment`, `confirm`, `refund`, `webhook`, `reconcile`.
• Webhooks com HMAC, retraí e backoff, dedução de eventos.
• Auto-recon (daily) + full-recon (periódico); armazenamento de UTR/árbitro.
• Tabela de Idempotação e mapa de estatais ('pending→success/expired').

11) Acerto e relatórios

Logue «paymentId/transactionId», «orderId», canal (Código/Push/QR/NFC), banco pagador, status, valor/moeda, timestamp, UTR/arbitragem bancária.
Os relatórios PSP incluem parâmetros de origem, atualizações tardias, devoluções ou devoluções parciais, cancelamentos.
Configure as alertas de raio e os frascos da SLA.

12) BLIK em iGaming/verticais de alto risco

A disponibilidade do BLIK depende de políticas PSP/bancos e direito local.
Espere limites mais rigorosos, KYC estendido, verificações do destinatário reforçadas e possíveis hold' s.
Mantenha os roteiros alternativos (mapas, SEPA, open-banking PIS) e um roteiro inteligente pelo perfil do jogador.

13) BLIK Contactless (detalhes da implementação)

Requer apoio do banco emissor e da infraestrutura terminal.
O UX é rápido (confira no aplicativo), mas os limites e antifrode podem ser diferentes do código/QR.
No relatório, use o canal NFC para monitorar conversões e falhas.

14) Folha de cheque de saída em proda

1. Selecione o PSP/Equeyer BLIK (online/POS/QR/NFC), negocie tarifas e SLA.
2. Implemente 'createPayment' + UX (Código/Push/QR/NFC) e erros/limites compreensíveis.
3. Ligue webhooks, idempotação, temporizações e repetições.
4. Inclua os refunds (partial/full), os procedimentos ODR e os corpons de safort.
5. Configure o recon (daily + full), armazenando UTR/arquivos finos.
6. Construa o monitoramento SLA através de canais (Código/Push/QR/NFC), alertas 'pending→expired'.
7. Cubra os testes end-to-end com bancos emissores, POS, ATM, plataformas móveis.

Cartão de referência de limites

Per-txn/24h/7d: armazenado no config e verificado antes do lançamento.
Novos destinatários/merchantes: liminares reduzidos e/ou extrato.
Canais: limites individuais para P2P, e-commerce, POS, ATM, NFC, QR.
Velocity/risco: O antifrode do banco pode desaconselhar/retardar as transações.

Currículo

Para online, aposte no BLIK OneClick/Push; para offline - QR dinâmico e Contactless.
Não use valores rígidos - use configs de limite de banco/canal.
A arquitetura é construída em torno de webhooks + recon, retornos parciais e processamento claro de 'pending/expired'.
Para o P2P, baseie-se em alias pelo número de telefone e mostre ao usuário os riscos contextuais e os limites.