PayID Australia: flujos NPP

1) Contexto: NPP y PayID

NPP (New Payments Platform) es la infraestructura de pago instantáneo nacional de Australia (24/7/365) con cálculos en tiempo real y un rico mensaje ISO 20022. PayID es una capa de direccionamiento en la parte superior de un NPP que permite pagar, no con BSB/Account, sino con un alias «humano»: número de teléfono, correo electrónico, ABN/ACN o ID de organización.

• Interoperabilidad: cualquier miembro de NPP ↔ cualquier banco emisor.
• Dirección de alias: el pagador ve el nombre de PayID antes de la confirmación (anti-misdirection).
• Instantáneo y final: el crédito en la cuenta de merchant se muestra inmediatamente; devoluciones por separado.
• Datos de pago: ISO 20022 con Remittens conveniente (asignación de pago, orderId, etc.).

2) Participantes y roles

NPP/esquema: enrutamiento y reglas.
Banco del pagador (Payer FI): autenticación del cliente, antifraude, envío de mensajes.
Banco receptor/ecuador (Payee FI): recepción de crédito, notificaciones, informes.
PSP/fintech: aplicaciones de primera línea, SDK, informes y reconciliation para merchantes.
Merchant: mantiene PayID (o datos bancarios), genera una solicitud/enlace al pagador.

3) Identificadores de PayID

Tipos de PayID: móvil, correo electrónico, ABN/ACN, ID de organización.

• A cada PayID se le asigna un nombre PayID que el pagador ve antes de confirmar.
• Una cuenta puede tener varios ID de PayD; la portabilidad entre bancos se mantiene mediante procedimientos de migración.
• ABN/ACN-PayID es conveniente para las empresas: es más fácil coincidir con el perfil de la empresa.

4) Flujos de pago básicos (NPP/PayID)

P2P (inserción): el pagador ingresa/escanea el PayID del destinatario → ve el nombre de PayID → confirma → crédito al instante.
P2M (push): el merchant publica PayID o emite deeplink/QR con una cantidad y metadatos prellenados.
Request-to-Pay (collect): el merchant inicia una solicitud de pago; el usuario confirma en la aplicación bancaria.

• Para el comercio electrónico, utilice deeplink/QR de suma fija y orderId.
• Para offline, permitiremos PayID estático, pero mejor es QR dinámico por pedido.

5) PayTo: e-mandates y automovilismo

• Merchant/PSP crea un mandato con parámetros (pagador, cuenta, límites, periodicidad, descripción).
• El pagador autorizará el mandato en su solicitud bancaria.
• El paso a pérdidas y ganancias se lleva a cabo automáticamente en el marco de las condiciones del mandato sin la autenticación manual de cada caso.
• Escenarios: suscripciones, servicios públicos/telco, planes regulares, facturación basada en usage con techo.

• Muestre al usuario los límites de mandato, la frecuencia y la fecha del próximo cargo.
• Mantenga el panel de control de mandatos (pause/cancel/update) y los hooks web sobre el estado.

6) Límites y controles de riesgo

• Per-transaction/Per-day: los umbrales bancarios para NPP/PayID pueden variar y cambiar.
• Nuevos destinatarios: a menudo se aplican límites de inicio reducidos y/o extracto.
• Políticas categóricas: Los funcionarios subalternos del cuadro orgánico/verticales pueden ser más estrictos.
• Mandatos de PayTo: los límites se establecen en el propio mandato (importe, período, cargo máximo).

• No codifique los importes: mantenga la guía de límites y actualice regularmente.
• En la interfaz, avisa de un posible exceso y sugiere el fraccionamiento de cheques si es admisible.

7) UX y seguridad

Confirmation of Payee-Ask Check: la visualización del nombre de PayID reduce el riesgo de error del destinatario.
2FA y device binding con el banco del pagador en el momento de la autorización.
Antifraude/velocity: los bancos tienen sus propias reglas; tenga en cuenta los posibles fallos «leves».
Transparencia: cheque con UTR/tiempo/suma/asignación + contactos de soporte.
Fallback: si deeplink no se ha abierto, ofrezca copia de PayID, QR estático e instrucciones.

8) Devoluciones y Dispouts

Charjback no está en el sentido de las cartas. Un reembolso es una nueva transacción de crédito del merchant al pagador con un enlace al UTR/OrderId original.
Mantenga los retornos parciales y la trazabilidad completa en los informes.
Las dispouts se resuelven a través de bancos/PSP y reglamentos de apoyo; anote el SLA y recopilar pruebas (registro de pedidos, entrega, correspondencia).

9) Integración de merchant: opciones

1. PayID estático

Comenzar rápidamente, un mínimo de desarrollo.
Riesgos: factor humano (ingreso de suma/comentario), más débil que el analista.

2. QR/deeplink dinámico

Generación por encargo: cantidad fija, orderId, remittens.
Mejor recon per-order, menos errores, mayor conversión.

3. Request-to-Pay

La «cuenta» del merchant → una confirmación del pagador.
Conveniente para facturación, B2B y servicios de suma variable.

4. PayTo (e-mandates)

Suscripciones/cancelaciones periódicas; el pagador administra el mandato en su banco.
Necesita pantallas de consentimiento, administración de límites, notificaciones antes de los cargos.

• Hooks de estado web (success/failure/pending), encuestas repetidas sobre backoff.
• Tabla de idempotencia (orderId + clave de consulta).
• Reconciliation por UTR/OrderId/tiempo/suma.
• Refund API y procedimientos ODR.
• Monitoreo SLA de bancos/PSP (latencia, éxito, códigos de error).

10) Conciliación e informes (ISO 20022, UTR)

UTR (ID de traducción único) es la clave principal de la conciliación; guarde tanto en el pago original como en la devolución.
Utilice los campos de destino/remisión ISO 20022 para orderId, Papelera de reciclaje, customerRef.
Configure el daily auto-recon (operativo) y el full-recon (financiero) periódico.
Informes PSP: transacciones, estados, mandatos de PayTo, devoluciones, rechazos.

11) Tarifas y costos

Para NPP/PayID, no hay un MDR clásico como en los esquemas de tarjetas, sin embargo, hay tarifas de proveedor de equipaje, módulos de PayTo, informes, paquetes SLA.
Tenga en cuenta los costos de soporte/dispouts, antifraude, generación de QR y alojamiento de páginas deeplink.

12) Opciones offline y QR

Merchant-presented QR (dinámico): óptimo para POS/caja registradora; la cantidad y los metadatos se cosen en el código.
QR estático: codifica PayID sin importe; el importe se introduce manualmente.
Impresión-en-cheque/en la placa: permitido para las pequeñas empresas, pero peor en la conciliación.

13) Cumplimiento, AML/CTF y privacidad

Cumpla con los requisitos de AML/CTF (AUSTRAC), almacenamiento de registros de transacciones/mandatos, niveles KYC en PSP.
Aplique el cribado de sanciones/frod a nivel de PSP, normas de Velocity, monitoreo de anomalías.
Procese los datos de PayID de acuerdo con los principios de minimización; muestre sólo lo que se requiere para UX y auditoría.

14) Características de alto riesgo (incluyendo iGaming)

Los bancos/PSP en Australia pueden restringir ciertas categorías según sus propias políticas de riesgo.
Espere límites reducidos, KYC reforzado y análisis de transacciones adicionales.
Planifique rieles alternativos para depósitos/pagos y un proceso de reembolso claro.

15) Arquitectura del servicio «NPP/PayID Gateway»

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Fiabilidad: retraídas por exponente, idempotencia, deduplicación de eventos.
Observabilidad: métricas (éxito/fallas/latencia), rastreos, alertas por SLA de los bancos.
Seguridad: HMAC firma web hooks, allowlist IP, rotación de secretos, registro de auditoría.
Datos: guías de límite individuales por banco/canal, estados de mandato de PayTo, tarjeta UTR.

16) Check-list de la salida en el prod

1. Obtenga un ID de PayD de Merchant (o un pool de ID de PayD) de un banco/PSP.
2. Seleccionar flujo: QR/deeplink dinámico, Request-to-Pay y/o PayTo.
3. Implementar hooks web, idempotencia y una tabla de mandatos.
4. Habilitar recon orientado a UTR (daily + full), alertas por rassincrones.
5. Iniciar Refund-flow (completo/parcial), registros ODR.
6. Agregar pantallas de límite UX, vista previa de nombre de PayID, errores claros.
7. Configure el monitoreo de SLA y los proveedores de dashboards.
8. Realice pruebas de fin a fin con diferentes bancos emisores y escenarios de PayTo.

Resumen

Para pagos desechables, apueste por QR/deeplink dinámico con metadatos ricos.
Para suscripciones y pagos periódicos, utilice los mandatos de PayTo con una administración UX transparente.
No codifique rígidamente los límites: mantenga las confecciones en los bancos/PSP y actualice.
Construya el proceso en torno a la conciliación UTR, la lógica detallada y la alerta SLA.