PayID Australia: fluxurile NPP

1) Context: NPP și PayID

NPP (New Payments Plats Platform) - infrastructura nationala de plati instant din Australia (24/7/365) cu decontari in timp real si un mesaj bogat ISO 20022. PayID este un strat de adresare deasupra NPP, care vă permite să plătiți nu prin BSB/Cont, ci prin alias „uman”: număr de telefon, e-mail, ABN/ACN sau ID-ul organizației.

• Interoperabilitate: orice participant la PNP ↔ orice bancă emitentă.
• Alias adresare: plătitorul vede numele PayID înainte de confirmare (anti-direcție greșită).
• Instantaneitate și finalitate: creditul în contul comerciantului este afișat imediat; retur - o operațiune separată.
• Date de plată: ISO 20022 cu remitență convenabilă (scopul plății, orderId etc.).

2) Membri și roluri

Rutare și reguli NPP/Schema

Payer bank (Payer FI): autentificare client, anti-fraudă, trimiterea unui mesaj.
Banca/achizitorul beneficiarului plății: acceptarea creditului, notificări, raportare.
PSP/fintech: aplicații din prima linie, SDK-uri, rapoarte și reconciliere pentru comercianți.
Comerciant: deține PayID (sau detalii bancare), generează o cerere/link către plătitor.

3) PayID-uri

Tipuri de PayID: mobil, e-mail, ABN/ACN, Organization ID.

• Fiecare PayID este asociat cu un nume PayID pe care plătitorul îl vede înainte de a confirma.
• Un singur cont poate avea mai multe PayID-uri; Portabilitatea transfrontalieră este susținută de procedurile de migrație.
• ABN/ACN-PayID sunt convenabile pentru afaceri: este mai ușor să se potrivească cu profilul companiei.

4) Fluxurile de plată de bază (NPP/PayID)

P2P (push): plătitorul intră/scanează PayID-ul beneficiarului plății → vede numele PayID → confirmă instantaneu creditul →.
P2M (push): comerciantul publică un PayID sau emite un deeplink/QR cu o cantitate preumplută și metadate.
Cerere-la-plată (colectare): comerciantul inițiază o cerere de plată; utilizatorul confirmă în aplicația bancară.

• Pentru comerțul electronic, utilizați deeplink/QR cu o sumă fixă și comenziID.
• Pentru offline, un PayID static este acceptabil, dar un QR dinamic pe comandă este mai bun.

5) PayTo: e-mandate și autocommissions

• Comerciant/PSP creează bilet cu parametri (plătitor, cont, limite, frecvență, descriere).
• Plătitorul autorizează mandatul în cererea sa bancară.
• Alte reduceri se efectuează automat în termenii mandatului, fără autentificarea manuală în fiecare etapă.
• Scenarii: abonamente, utilitate/telco, planuri regulate, facturare bazată pe utilizare cu plafon.

• Arată utilizatorului limitele biletului, frecvența și data următoarei taxe.
• Păstrați panoul de control al biletelor (pauză/anulare/actualizare) și cârligele web despre statusuri.

6) Limite și controlul riscurilor

• Per-tranzacție/Per-zi: Pragurile bancare pentru NPP/PayID pot varia și variază.
• Destinatari noi: Limitele de pornire reduse și/sau viteza obturatorului sunt adesea în vigoare.
• Politici categorice: MCC individuale/verticale pot avea o înăsprire.
• Bilete PayTo: limitele sunt stabilite în biletul propriu-zis (sumă, perioadă, notă maximă).

• Nu hardcode cantități - păstrați directorul limită și actualizați în mod regulat.
• În interfața, avertizează cu privire la un posibil exces și sugerează divizarea verificărilor, dacă este posibil.

7) UX și securitate

Confirmarea verificării asemănătoare cu a beneficiarului plății: afișarea numelui PayID reduce riscul de eroare a destinatarului.
2FA și dispozitivul obligatoriu la banca plătitorului în momentul autorizării.
Antifraudă/viteză: băncile au propriile reguli; consideră posibile eșecuri „moi”.
Transparență: verificați cu UTR/timp/sumă/scop + contacte de sprijin.
Rezervă: Dacă deeplink-ul nu s-a deschis, oferiți copierea PayID, QR static și instrucțiuni.

8) Returnări și dispute

Nu există încărcătoare în sensul cardului. Returul este o nouă tranzacție de credit de la comerciant la plătitor cu referire la originalul UTR/OrderId.
Suportă returnările parțiale și trasabilitatea completă în rapoarte.
Litigiile sunt rezolvate prin intermediul băncilor/PSP-urilor și reglementărilor de sprijin; pune SLA și colectarea probelor (jurnalul comenzii, livrarea, corespondența).

9) Integrarea comerciantului: Opțiuni

1. PayID static

Începeți rapid, dezvoltare minimă.
Riscuri: factor uman (introducere cantitate/comentariu), analiză mai slabă.

2. QR dinamic/deeplink

Generare la comandă: sumă fixă, comandăId, remitență.
O mai bună recunoaștere pe comandă, mai puține erori, conversie mai mare.

3. Cerere-la-plată

„Factura” de la comerciant → confirmarea de la plătitor.
Utile pentru servicii de facturare, B2B și cantitate variabilă.

4. PayTo (e-mandate)

Abonamente/taxe periodice; plătitorul gestionează mandatul la banca lor.
Avem nevoie de ecrane de consimțământ, gestionarea limitelor, notificări înainte de a scrie-off-uri.

• Cârlige web de stare (succes/eșec/în așteptare), sondaje repetate de backoff.
• Tabel de idempotență (comandăID + cheie de interogare).
• Reconcilierea prin UTR/OrderId/timp/sumă.
• Rambursarea API-urilor și a procedurilor SOL.
• Monitorizarea bancară/PSP SLA (latență, succes, coduri de eroare).

10) Reconciliere și raportare (ISO 20022, UTR)

UTR (identificator unic de transfer) - cheie principală de reconciliere; Păstrați atât plata inițială, cât și returnarea.
Utilizați câmpurile de atribuire/remitere ISO 20022 pentru comandăId, coș, customerRef.
Configurați zilnic auto-recunoaștere și periodic full-recon.
Rapoarte PSP: tranzacții, statusuri, bilete PayTo, retururi, abateri.

11) Tarife și costuri

Pentru NPP/PayID nu există un MDR clasic ca în schemele de carduri, cu toate acestea, există taxe de furnizor pentru achiziționarea, module PayTo, raportare, pachete SLA.
Luați în considerare costurile de suport/litigii, anti-fraudă, generarea QR și deeplink pagina de găzduire.

12) Opțiuni offline și QR

QR (dinamic) prezentat de comerciant: optim pentru POS/checkout; cantitatea și metadatele sunt protejate în cod.
Static QR: codifică PayID fără sumă; Introduceți suma manual.
Print-on-check/pe placa: permis pentru întreprinderile mici, dar mai rău pentru reconciliere.

13) Conformitate, AML/CTF și confidențialitate

Respectați AML/CTF (AUSTRAC), stocarea jurnalului de tranzacții/bilete, nivelurile KYC în PSP.
Aplicați screeningul de sancțiune/fraudă la nivelul PSP, regulile de viteză, monitorizarea anomaliilor.
Procesarea datelor PayID conform principiilor de minimizare; Arată doar ceea ce este necesar pentru UX și audit.

14) Caracteristici cu risc ridicat (inclusiv iGaming)

Băncile/PSP din Australia pot restricționa categoriile individuale pe propriile politici de risc.
Așteptați limite reduse, KYC consolidat și analize suplimentare ale tranzacțiilor.
Planificați șine alternative pentru depozite/rambursări și un proces clar de returnare.

15) Arhitectura serviciului Gateway NPP/PayID

API: 'createPaymentIntent', 'generateDynamicQR', 'requestToPay', 'createPayToMandate', 'rambursare', 'reconciliere', 'webhook'.
Fiabilitate: Retrăiți exponențial, idempotență, deduplicare de evenimente.
Observabilitate: valori (succes/eșecuri/latență), urme, alerte pe băncile SLA.
Securitate: semnătura HMAC a cârligelor web, IP-ul listei de permisiuni, rotația secretelor, jurnalul de audit.
Date: directoare individuale de limite de către bănci/canale, statusuri de mandat PayTo, card UTR.

16) Lista de verificare de ieșire

1. Obțineți PayID-ul comerciantului (sau piscina PayID) de la bancă/PSP.
2. Selectați un flux: QR/deeplink dinamic, Request-to-Pay și/sau PayTo.
3. Implementați cârlige web, idempotență și o masă de bilete.
4. Activați recunoașterea orientată către UTR (zilnic + complet), alerte prin aliniere greșită.
5. Rulați fluxul de rambursare (complet/parțial), jurnalele SOL.
6. Adăugați ecrane limită UX, previzualizare nume PayID, erori ușor de înțeles.
7. Configurați tablouri de bord de monitorizare SLA și furnizor.
8. Efectuați teste complete cu diferite bănci emitente și scenarii PayTo.

Rezumat reluare

Pentru plăți unice, pariați pe QR/deeplink dinamic cu metadate bogate.
Pentru abonamente și plăți recurente, utilizați bilete PayTo cu management transparent UX.
Nu aveți limite de cod dure: păstrați configurațiile bancare/PSP și actualizați.
Construiți un proces în jurul reconcilierii UTR, înregistrării detaliate și alertării de către SLA.