PayID Austrália: fluxos NPP

1) Contexto: NPP e PayID

A NPP é uma infraestrutura nacional de pagamentos instantâneos da Austrália (24/7/365) com cálculos em tempo real e uma rica mensagem ISO 20022. PayID é uma camada de direcionamento acima do NPP, que permite pagar não por BSB/Account, mas por alias «humanas»: número de telefone, e-mail, ABN/ACN ou Organization ID.

• Interoperabilidade: Qualquer membro do NPP ↔ qualquer banco emissor.
• Endereço alias: o pagador vê o PayID Name antes da confirmação (anti-misdirecção).
• Instantaneidade e finalidade: crédito na conta do Merchant é exibido imediatamente; a devolução é uma operação separada.
• Dados de pagamento: ISO 20022 com remittence fácil (destino do pagamento, orderId etc.).

2) Participantes e papéis

NPP/esquema: rotação e regras.
Banco Pagador (Payer FI): autenticação do cliente, antifrode, envio de mensagem.
Banco de destinatário/equador (Payee FI): aceitação de crédito, notificações, relatórios.
PSP/fintech: aplicativos de frente, SDK, relatórios e reconciação para merchantes.
Merchant: mantém PayID (ou adereços bancários), gera um pedido/link ao pagador.

3) Identificadores de PayID

Tipos de PayID: celular, email, ABN/ACN, Organização ID.

• Cada PayID é comparado ao PayID Name que o pagador vê antes da confirmação.
• Uma conta pode ter vários PayID; a portabilidade entre os bancos é suportada pelos procedimentos de migração.
• Para os negócios, é mais fácil corresponder ao perfil da empresa.

4) Fluxos básicos de pagamento (NPP/PayID)

P2P (push): o pagador digita/escaneia o PayID do destinatário → vê o PayID Name → confirma o crédito → instantaneamente.
P2M (push): O merchant publica PayID ou emite deplink/QR com soma preenchida e metadados.
Request-to-Pay (collect): o merchant inicia o pedido de pagamento; o usuário confirma no aplicativo bancário.

• Para o e-commerce, use deplink/QR com soma fixa e orderId.
• Para um offline, permitamos um PayID estático, mas melhor: um QR per-order dinâmico.

5) PayTo: e-mandates e xixi automático

• Merchant/PSP cria um mandato com parâmetros (pagador, conta, limite, periodicidade, descrição).
• O pagador autoriza o mandato em seu aplicativo bancário.
• Os cancelamentos seguem automaticamente dentro dos termos do mandato, sem autenticação manual diária.
• Cenários: subscrição, público/telco, planos regulares, usage-based billing com teto.

• Mostre aos usuários os limites de mandato, a frequência e a data do próximo cancelamento.
• Mantenha o painel de controle de mandatos (pause/cancel/update) e os ganchos de status.

6) Limites e controle de risco

• Por-transmissão/Per-day - liminares bancários para NPP/PayID podem variar e variar.
• Novos destinatários: com frequência, os limites de partida e/ou extrato são reduzidos.
• Políticas categóricas: MSS/vertical individuais podem ter rigor.
• Mandatos PayTo: os limites são definidos no próprio mandato (valor, período, desconto máximo).

• Não hardcode os valores - guarde o guia de limites e atualize regularmente.
• Na interface, avise sobre eventuais excesso e sugira que os cheques sejam cortados se isso for permitido.

7) UX e segurança

Confirmation of Payee é uma verificação semelhante: exibir PayID Name reduz o risco de erro do destinatário.
2FA e device binding junto ao banco pagador no momento da autorização.
Antifrod/velocity: os bancos têm suas próprias regras; leve em consideração as possíveis falhas «suaves».
Transparência: cheque UTR/hora/valor/destino + contatos de suporte.
Fallback: Se o deplink não abrir, sugira cópia de PayID, QR estático e instruções.

8) Devoluções e displays

O Charjback não está no sentido de cartas. O reembolso é uma nova transação a partir do merchant ao pagador com referência ao UTR/OrderId de origem.
Mantenha retornos parciais e rastreabilidade completa nos relatórios.
Os displays são resolvidos através de bancos/PSP e regulamentos de suporte; coletar SLA e coletar provas (logos da encomenda, entrega, correspondência).

9) Integração do merchant: opções

1. Um PayID estático

Rápido para começar, mínimo desenvolvimento.
Riscos: fator humano (digitar soma/comentário), mais fraco que o analista.

2. QR dinâmico/deplink

Geração sob medida: valor fixo, orderId, remittens.
Melhor per-order recon, menos erros, conversão superior.

3. Request-to-Pay

«Conta» do Merchant → confirmação do pagador.
Fácil para faturamento, B2B e serviços de quantia variável.

4. PayTo (e-mandates)

Assinaturas/cancelamentos regulares; O pagador administra o mandato no seu banco.
Precisamos de ecrãs de consentimento, gerenciamento de limites, notificações antes de cancelamentos.

• Ganchos de status da Web (sucess/failure/pending), sondagens de backoff repetidas.
• Tabela de Idempotação (orderId + chave de consulta).
• Reconciação por UTR/OrderId/hora/montante.
• Refund API e procedimentos ODR.
• Monitoramento de bancos SLA/PSP (latência, sucesso, códigos de erro).

10) Processamento e relatórios (ISO 20022, UTR)

UTR (ID único de tradução) - chave principal de confecção; guarde no pagamento inicial e no reembolso.
Use os campos de destino/remittens ISO 20022 para orderId, cesta, customerRef.
Configure o daily auto-recon (operacional) e o full-recon periódico (financeiro).
Relatórios PSP: transações, estatais, mandatos de PayTo, devoluções, desvios.

11) Tarifas e custos

Não existe um MDR clássico como os sistemas de cartão, mas há taxas de fornecimento de equação, módulos de , relatórios, pacotes SLA.
Leve em conta os custos de suporte/display, antifrode, geração de QR e hospedagem de páginas deplink.

12) Opções off-line e QR

Merchant-presented QR (dinâmico): ideal para POS/caixa; soma e metadados são costurados no código.
QR estático: codifica PayID sem valor; a quantia é digitada manualmente.
Impressão-em-cheque/placa: É permitido para pequenas empresas, mas é pior que isso.

13) Complaens, AML/CTF e privacidade

Cumpra os requisitos AML/CTF (Australac), armazenamento de logs de transações/mandatos, níveis KYC no PSP.
Use o screening de sanções/frod no nível PSP, regras Velocity, monitoramento de anomalias.
Os dados PayID sejam tratados de acordo com os princípios de minimização; mostre apenas o que é necessário para o UX e para a auditoria.

14) Características de high-risk (incluindo iGaming)

Os bancos/PSP na Austrália podem limitar as categorias individuais de suas próprias políticas de risco.
Espere os limites reduzidos, o KYC reforçado e os analistas adicionais de transações.
Planeje roteiros alternativos para depósitos/pagamentos e um processo claro de reembolso.

15) Arquitetura do serviço «NPP/PayID Gateway»

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Confiabilidade: retraí por exposição, idempotidade, dedução de eventos.
Observabilidade: métricas (sucesso/falhas/latência), seguimentos, alertas de banco SLA.
Segurança: HMAC assinatura Web Hook, allowlist IP, rotação de segredos, registro de auditoria.
Dados: guias individuais de limites de banco/canal, estatais de mandatos PayTO, cartão UTR.

16) Folha de cheque de saída em proda

1. Obter o PayID merchant (ou pool de PayID) do banco/PSP.
2. Selecione o fluxo QR/deplink dinâmico, Request-to-Pay e/ou PayTo.
3. Implementar a Web Hook, Idempotidade e tabela de mandatos.
4. Incluir recon orientado UTR (daily + full), alertas por rashincrons.
5. Iniciar o Refund-flow (completo/parcial), revistas ODR.
6. Adicionar ecrãs UX de limites, suprir PayID Name, erros compreensíveis.
7. Ajustar monitoramento de SLA e dashboards de provedor.
8. Fazer testes end-to-end com diferentes bancos emissores e cenários de PayTo.

Currículos

Para opulentos descartáveis, aposte em QR dinâmico/deplink com metadados ricos.
Para subscrever e pagar regularmente, use os mandatos PayTo com controle UX transparente.
Não codifique severamente os limites: mantenha os configs pelos bancos/PSP e atualize.
Construa o processo em torno do cruzamento UTR, do loging detalhado e do alerting por SLA.