Vales em dinheiro e redes de retail

1) O que é e quando aplicar

Os vales em dinheiro e as redes eCash permitem aceitar o pagamento sem cartões bancários ou IBAN. O usuário compra o voucher pré-pago (PIN) ou recebe o código de barras/QR (pay-at-store) e paga a reserva no ponto offline do parceiro (quiosque, supermercado, ASS, correio) ou no banco online/ATM. O dinheiro vem do Merchant através do PSP/Provedor de Serviços Bancários; charjback não, os riscos de frod são mínimos.

• Produtos digitais/jogos, conteúdo, assinaturas com cheque baixo/médio.
• Regiões com alta proporção de dinheiro ou baixo cartão-pena.
• Públicos que preferem privacidade/pagamento antecipado.

2) Tipologia de ferramentas eCash

1. Vales PIN (códigos pré-pagos):

Exemplos: Paysafecard, Neosurf, Flexepin.
UX: Digite um PIN de 16/10 dígitos no formulário de hospedagem ou pagamento da carteira (myPaysafe/myNeosurf).
Características: débitos parciais, combinação de vários PIN, o restante é preservado.

2. Código de barras/QR «Pagar na loja» (cash payment barcode):

Exemplos: paysafecash, redes locais (OXXO Pay - MX, RapiPago/PagoFácil - AR, Efecty/Baloto - CO, PayPoint/Payzone - UK, ePay/Paylink - EU, etc).
UX: O merchant gera barcode/QR → o cliente paga em dinheiro na caixa → o provedor envia a confirmação.
Características: o cheque é válido por tempo limitado (expedy) e o valor é fixo.

3. Reference/Slip para ATM/online banking (adereços de fatura):

Exemplos: Referências Multibanco - PT, Konbini - JP.
UX: Exibe código/arbitragem + valor, pagamento em ATM/banco on-line/loja parceira.
Características: mínimo de frodo, verificação rigorosa de arbitragem.

3) Membros do ecossistema

Provedor/esquema (eCash/vales): produz PIN/barkods, guia catálogos de retail, KYC/AML, antifrode, dá API/widgets.
PSP/Equyer: conecta merchant, caixa de hospedagem/SDK, estatais, webhooks, registros e cálculos.
Ritail/caixa: recepção em dinheiro/leitura de código de barras, sincronização com o provedor.
Banco/Clearing: cálculo e pagamento de merchant.
Merchant: inicia o pagamento/fatura, processa estatais, restituições e recon.

4) Fluxos de pagamento

4. 1 voucher PIN (Hosted/Redirect)

1. Checkout → uma seleção de eCash (por exemplo, Paysafecard/Neosurf).
2. Redirect/Hosted formulário do provedor → entrada PIN/entrada na carteira → confirmação (SCA/personalização comportamental).
3. Retorno ao merchant: 'sucess/pending/failed/canceled/expired'.
4. Crédito real - por registros diários (T + 1/T + 2).

4. 2 Código de barras/QR «pagar na loja»

1. Merchant cria a fatura: soma + barcode/QR + expedy.
2. O cliente vai ao ponto de venda e paga em dinheiro → a caixa confirma a operação do provedor.
3. O provedor envia o merchant para o sucesso online, o crédito nos registros (T + 0/T + 1).

4. 3 Reference/Slip (ATM/online-banking/conbini)

1. Geração de arbitragem (entity/reference/amount) + validade.
2. Pagamento em ATM/banco online/loja parceira.
3. Status on-line 'paid' e subsequente no registro.

5) Estados e cálculos

Estatais online: 'created '/' pending '/' sucess' paid '/' failed '/' canceled '/' expired '.
Senslement: normalmente T + 0/T + 2 dias bancários (por contrato/canal).
Na lógica do negócio, compartilhe a confirmação online e o crédito real.

6) Limites, KYC e risco

• Por-transmissão, 24h/7d, limite de PIN por pagamento/dia.
• Para novos destinatários/merchantes - liminares reduzidos/extrato.
• Geo-regras (país de voucher vs localização cliente/merchant), velocity, sinais device.
• Nenhum Charjback; display - por OTR do provedor/PSP.
• Recomendação: mantenha os limites de config por país/rede/CUS e não hardcode os valores.

7) Devoluções e cancelamentos parciais

Refund = nova operação de empréstimo (para a carteira eCash/transferência bancária - de acordo com as regras do provedor).
Os refunds Partial são normalmente suportados.
Para os vales PIN são frequentemente disponíveis cancelamentos parciais e combinação de PIN; para as faturas barcode - o valor é fixo.

8) Economia e tarifas

A comissão para Merchant normalmente é inferior ao MDR de cartão CNP, mas varia em geo/volume/categoria.
Adição: hospedagem/SDK, publicidade de ponto de venda, safort/ODR, processamento de 'expired/pending', recon.

9) Pattern UX

Pagamento PIN: UI compreensível para vários PIN e indicador de saldo; mensagens de erro: «errado/usado», «limite ultrapassado», «região não suportada».
Barcode/QR: grande código + tempo de validade, botões «imprimir/enviar para messenger/email».
Instruções de pagamento offline: 3 a 4 passos com logótipos de rede; mapa dos pontos mais próximos/horários de trabalho.
Estado da ordem: «Espera pagamento» com atualização automática; «expired» é o botão «criar um novo código».
Recibo: valor, hora, 'paymentId', canal (PIN/Barcode/Reference), UTR/ref. registos, contatos de safort.
Localização: divisas/linguagem/textos fiscais, marcas locais de redes.

10) Segurança e conformidade

PII-Minimização: PIN/carteira são introduzidos do lado do provedor (Hosted/Widget).
Ganchos da Web: HMAC/nonce, protecção contra replay, verificação de eventos, registro de auditoria.
KYC/AML/GDPR: Regras de idade/limite para pré-pagos, sanções/geo-restrições.
Antifrod: limites por dispositivo/sessão, cooling-off, step-up, monitoramento de PIN/barkods repetidos.

11) Integração e arquitetura

Opções de conexão

1. Hosted/Embedded em PSP/Provedor é um lançamento rápido, o mínimo responsável pelos dados sensíveis.
2. O Server-to-Server + Hosted é um check-out próprio, com controle de estatais, sem processamento de PIN.
3. Pay-by-Link/Invoice - pagamentos de referência e sacolas.

O mínimo de Backend

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotidade ('orderId' + chave), retraias exponenciais, DLQ, Web Hoop.
Diretórios: países/redes/limites/níveis CUS, códigos de erro, métricas SLA nos canais.
Observabilidade: Conversão (PIN vs Barcode/Reference), proporção de 'pending→expired', média de tempo antes do pagamento/masslement, geo-anomalias.

12) Notas geográficas (orientações)

Европа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
Ásia: Konbini (JP) e redes locais (FamilyMart/Lawson/7-Eleven).

13) Folha de cheque de saída em proda

1. Selecione o provedor/PSP e as redes de destino (PIN/Barcode/Reference) e negocie as tarifas/SLA/masslement.
2. Implemente 'createPayment'createInvoice' com expedy, páginas de instruções e cenários fallback.
3. Conecta webhooks (HMAC), idempotidade, retraí e dedução de eventos.
4. Configure o daily auto-recon + full-recon, armazene a instrução UTR/Finn.
5. Inclua partial refunds, procedimentos ODR e mensagens de falha/limite compreensíveis.
6. Execute SLA-dashboards (conversão, 'expired', até o pagamento/masslement) e alertas por rashincrons.
7. Faça testes e2e: PIN múltiplo, código de barras atrasado, valor inválido, pagamento duplo, reembolso em partes.

Cartão de referência

Статусы: `created/pending/success|paid/failed/canceled/expired`.
Senslement: normalmente T + 0-T + 2 nos registros PSP/provedor.
Chargeback: ausente; O refund é um empréstimo separado.
Limites/CUS: Dependem do país/rede/canal e perfil do cliente.
Recurrent: primeiro eCash → mandato (SEPA/Open-Banking/Local) para cancelamentos posteriores.

Currículo

Estratégia: eCash-mix (PIN + barcode/QR + reference) para cobrir o público em dinheiro e reduzir o MDR.
Arquitetura em torno de webhooks + recon, idempotidade rigorosa e OX 'pending/expired' compreensível.
Configs de limite/CUS e regras geo - fora do código, com atualização regular.
Para assinaturas, primeiro eCash → mandato, gerenciamento transparente e notificações para o usuário.