PayID Australia: flussi NPP

1) Contesto: NPP e PayID

NPP (New Payments Platform) è un'infrastruttura di pagamento istantanea nazionale australiana (24/7/365) con calcoli in tempo reale e un ricco messaggio ISO 20022. PayID è un livello di indirizzo sopra NPP che non consente di pagare BSB/Account, ma un alias «umano»: numero di telefono, email, ABN/ACN o Organization ID.

• Interoperabilità: tutti i membri della NPP ↔ qualsiasi banca emettitrice.
• Indirizzi alias: il pagatore vede il PayID Name prima della conferma (anti-misdirection).
• Immediatezza e finalità: il credito sul conto merchant viene visualizzato immediatamente; Restituzione: operazione separata.
• Dati di pagamento: ISO 20022 con comodo remittence (destinazione del pagamento, ecc.).

2) Membri e ruoli

Routing e regole NPP/schema.
Payer FI - Autenticazione client, antifrode, invio messaggio.
Banca destinatario/equayer (Payee FI) - Accetta prestiti, notifiche, rapporti.
PSP/Fintech: applicazioni frontali, SDK, report e riconducibili ai merchant.

3) Identificatori di PayID

Tipi di PayID: cellulare, email, ABN/ACN, Organizzazione ID.

• Ogni PayID è PayID Name, che il pagatore vede prima della conferma.
• Un conto può avere più PayID; la portabilità tra banche è supportata dalle procedure di migrazione.
• Per le aziende, è più facile adattarsi al profilo aziendale.

4) Flussi di pagamento di base (NPP/PayID)

P2P (push) - Il pagatore immette/scansiona il del destinatario Name conferma il credito

P2M (push) - Il Merchant pubblica o rilascia deplink/QR con somma e metadati predefiniti.
Richiest-to-Pay (collect) - Avvia una richiesta di pagamento l'utente conferma nell'applicazione bancaria.

• Per l'e-commerce, utilizzare deeplink/QR a somma fissa e orderId.
• Per l'offline, ammettiamo il PayID statico, ma meglio il QR dinamico per-order.

5) PayTo: e-mandates e compressione automatica

• Merchant/PSP crea un mandato con parametri (pagatore, fattura, limiti, frequenza, descrizione).
• Il pagatore autorizza il mandato sulla propria applicazione bancaria.
• I passaggi successivi vengono effettuati automaticamente in base alle condizioni del mandato senza autenticazione manuale giornaliera.
• Scenari: abbonamenti, locali/telco, piani regolari, usage-based billing con soffitto.

• Visualizzare all'utente i limiti di mandato, la frequenza e la data del prossimo prelievo.
• Mantieni il pannello di controllo dei mandati (pausa/cancel/update) e il gancio Web sugli stati.

6) Limiti e rischio-controllo

• Per-trasmissione/Per-day - le soglie bancarie possono variare e cambiare.
• Nuovi destinatari: spesso i limiti di partenza e/o di avanzamento sono ridotti.
• Criteri categorici: i singoli MSS/verticali possono avere rigidità.
• PayTo-mandati: i limiti vengono impostati nel mandato stesso (importo, periodo, addebito massimo).

• Non aggiungere le somme - Memorizza la guida dei limiti e aggiorna regolarmente.
• In questa interfaccia è possibile superare il limite e proporre il frammentamento degli assegni, se consentito.

7) UX e sicurezza

Confirmation of Payee è un controllo simile: visualizza il PayID Name riduce il rischio di errore del destinatario.
2FA e device binding presso la banca pagatrice al momento dell'autorizzazione.
Antifrode/velocity: le banche hanno le proprie regole; tenete conto dei possibili guasti «morbidi».
Trasparenza: assegno UTR/ora/importo/destinazione + contatti di supporto.
Fallback: se il deeplink non si apre, suggerisci di copiare il PayID, il QR statico e le istruzioni.

8) Restituzioni e display

Charjback non è in termini di carte. La restituzione è una nuova transazione da merchant al pagatore con riferimento al UTR/OrderId originale.
Mantenere i ritorni parziali e la tracciabilità completa nei report.
I display vengono risolti tramite banche/PSP e regolamenti di supporto; depositare SLA e raccogliere prove (login, spedizione, corrispondenza).

9) Integrazione merchant: opzioni

1. PayID statica

Presto per partire, minimo sviluppo.
I rischi sono il fattore umano (immissione di somma/commento), più debole dell'analista.

2. QR/deeplink dinamico

Generazione su misura: somma fissa, orderId, remittance.
Miglior per-order recon, meno errori, maggiore conversione.

3. Request-to-Pay

Il conto del Merchant ha dato conferma al pagatore.
Comodo per fattura, B2B e servizi a somma variabile.

4. PayTo (e-mandates)

Abbonamenti/prelievi regolari; Il pagatore gestisce il mandato nella sua banca.
Servono schermate di consenso, controllo dei limiti, notifiche prima dei prelievi.

• Hookie di stato Web (success/failure/pending), interrogatori di backoff ripetuti.
• Tabella di idempotenza (orderId + chiave di query).
• Ricomposizione per UTR/OrderId/tempo/somma.
• Procedure di Rifund API e ODR.
• Monitoraggio SLA banche/PSP (latitanza, successo, codici di errore).

10) Accoppiamento e reporting (ISO 20022, UTR)

UTR (ID univoco di traduzione) - chiave principale di riconciliazione; salvare sia sul pagamento originale che sul rimborso.
Usa i campi di destinazione/remittens ISO 20022 per orderId, cestino, customerRef.
Configurare il daily auto-recon (operativo) e il full-recon periodico (finanziario).
Report PSP: transazioni, stati, mandati di PayTo, restituzioni, deviazioni.

11) Tariffe e costi

Non esiste un MDR classico come nei circuiti di mappe, ma ci sono costi di fornitura per equairing, moduli di , rapporti, pacchetti SLA.
Tenere conto dei costi di supporto/display, antifrode, generazione QR e hosting deeplink.

12) Opzioni off-line e QR

Merchant-presented QR (dinamico): ottimale per POS/biglietteria; l'importo e i metadati sono stati ricuciti nel codice.
QR statico: codifica il PayID senza importo; la somma viene immessa manualmente.
Stampa-in-assegno/cartello: è consentito per le piccole imprese, ma peggiora in termini di compressione.

13) Complaence, AML/CTF e privacy

Rispettare i requisiti AML/CTF (AUSTRALAC), conservare i fogli di transazione/termine, i livelli KYC in PSP.
Applicare lo screening di sanzioni/frod a livello PSP, le regole Velocity, il monitoraggio delle anomalie.
Elaborare i dati in base ai principi di minimizzazione; Mostra solo ciò che è necessario per il controllo UX e il controllo.

14) Caratteristiche high-risk (inclusa la iGaming)

Le banche/PSP in Australia possono limitare le singole categorie in base alle proprie politiche di rischio.
Attesi limiti ridotti, un aumento di KYC e ulteriori analisi delle transazioni.
Pianificare binari alternativi per depositi/rimborsi e un processo chiaro di rimborso.

15) Architettura del servizio «NPP/PayID Gateway»

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Affidabilità: retrai in modo esponenziale, idempotenza, deduplicazione degli eventi.
Osservabilità: metriche (successo/rifiuto/latitanza), tracciabili, alert SLA banche.
Sicurezza: HMAC firma web hook, allowlist IP, rotazione dei segreti, registro di controllo.
Dati: elenchi specifici dei limiti bancari/canali, stato dei mandati PayTo, scheda UTR.

16) Assegno foglio di output

1. Ottieni un PayID merchant (o un pool di PayID) dalla banca/PSP.
2. Seleziona flusso: QR/deeplink dinamico, Richiest-to-Pay e/o PayTo.
3. Implementare il Web Hook, Idempoted e la tabella dei mandati.
4. Abilita recon orientato UTR (daily + full), alert di rassincroni.
5. Avvia Rifund flow (completo/parziale), registri ODR.
6. Aggiungi schermate UX dei limiti, prevale il PayID Name, errori chiari.
7. Configura il monitoraggio SLA e i dashboard di provider.
8. Eseguire test end-to-end con banche emittenti e scenari diversi.

Curriculum

Per gli ingranaggi monouso, scommettere su un QR/deeplink dinamico ricco di metadati.
Per sottoscrizioni e pagamenti regolari, utilizzare i mandati PayTo con gestione UX trasparente.
Non codificare in modo rigido i limiti, mantenere i configi su banche/PSP e aggiornare.
Creare un processo intorno al processo UTR, alla logica dettagliata e all'alerting SLA.