PayID Australia: przepływy NPP

1) Kontekst: NPP i PayID

NPP (New Payments Platform) - australijska krajowa infrastruktura natychmiastowej płatności (24/7/365) z rozrachunkami w czasie rzeczywistym i bogatym komunikatem ISO 20022. System PayID jest warstwą adresową NPP, która pozwala płacić nie przez BSB/Konto, ale przez alias „ludzki”: numer telefonu, e-mail, ABN/ACN lub ID organizacji.

• Interoperacyjność: każdy uczestnik NPP - wszelkie banki emitujące.
• Adres aliasu: przed potwierdzeniem (anty-misdirection) płatnik widzi nazwę PayID.
• Natychmiastowość i finalność: kredyt na koncie handlowca jest natychmiast wyświetlany; zwrot - osobna operacja.
• Dane dotyczące płatności: ISO 20022 z wygodnym przekazem pieniężnym (cel płatności, Id, itp.).

2) Członkowie i role

NPP/Schema Routing i zasady

Bank płatnika (Payer FI): uwierzytelnianie klienta, zwalczanie oszustw, wysyłanie wiadomości.
Bank odbiorcy/nabywca (Payee FI): akceptacja pożyczek, powiadomienia, sprawozdawczość.
PSP/fintech: aplikacje front-line, SDK, raporty i pojednanie dla handlowców.
Handlowiec: posiada identyfikator PayID (lub dane bankowe), generuje żądanie/link do płatnika.

3) Dokumenty PayID

Rodzaje usług PayID: telefon komórkowy, e-mail, ABN/ACN, identyfikator organizacji.

• Każdy dokument PayID jest powiązany z nazwą PayID, którą płatnik widzi przed potwierdzeniem.
• Pojedyncze konto może mieć wiele dokumentów PayID; Przenoszenie transgraniczne jest wspierane przez procedury migracji.
• ABN/ACN-PayID są wygodne dla biznesu: łatwiej jest dopasować profil firmy.

4) Podstawowe przepływy płatnicze (NPP/PayID)

P2P (push): płatnik wchodzi/skanuje PayID odbiorcy → widzi nazwę PayID → potwierdza → kredytu natychmiast.
P2M (push): handlowiec publikuje dokument PayID lub wydaje deeplink/QR z fabrycznie wypełnioną kwotą i metadanymi.
Żądanie zapłaty (zbieranie): handlowiec inicjuje żądanie zapłaty; użytkownik potwierdza w aplikacji bankowej.

• W przypadku handlu elektronicznego należy użyć deeplink/QR ze stałą kwotą i Id.
• W przypadku usług offline statyczny identyfikator PayID jest akceptowalny, ale dynamiczny QR na zamówienie jest lepszy.

5) PayTo: e-mandaty i autokomisje

• Handlowiec/PSP tworzy bilet z parametrami (płatnik, konto, limity, częstotliwość, opis).
• Płatnik upoważnia mandat w swojej aplikacji bankowej.
• Kolejne odpisy są przeprowadzane automatycznie w ramach mandatu bez uwierzytelniania instrukcji każdego kroku.
• Scenariusze: abonamenty, usługi użyteczności publicznej/telco, regularne plany, rozliczenia oparte na użyciu z sufitem.

• Pokaż użytkownikowi limity biletu, częstotliwość i datę następnej opłaty.
• Zachowaj panel kontroli biletu (pauza/anulowanie/aktualizacja) i haki internetowe o statusach.

6) Ograniczenia i kontrola ryzyka

• Transakcja/Dziennie: Progi bankowe dla NPP/PayID mogą się różnić i różnić.
• Nowi odbiorcy: Zmniejszone limity początkowe i/lub prędkość migawki są często skuteczne.
• Kategoria polityki: poszczególne MCC/piony mogą mieć zaostrzenie.
• Bilety PayTo: limity są ustalane w samym bilecie (kwota, okres, maksymalna umorzenie).

• Nie hardcode kwoty - zachować katalog limitów i aktualizować regularnie.
• W interfejsie, ostrzec o możliwym nadmiarze i sugerować podział kontroli, jeśli to możliwe.

7) UX i bezpieczeństwo

Potwierdzenie weryfikacji typu odbiorcy: wyświetlanie nazwy PayID zmniejsza ryzyko błędu odbiorcy.
2FA i urządzenie wiążące w banku płatnika w momencie autoryzacji.
Antyfraud/prędkość: banki mają własne zasady; rozważyć ewentualne „miękkie” awarie.
Przejrzystość: sprawdź za pomocą UTR/time/amount/purpose + wsparcie kontaktów.
Fallback: Jeśli deeplink nie został otwarty, zaoferuj kopiowanie systemu PayID, statyczne QR i instrukcje.

8) Zwroty i spory

Nie ma ładowarek w sensie karty. Zwrot jest nową transakcją kredytową od handlowca do płatnika z odniesieniem do oryginalnego UTR/ Id.
Wsparcie częściowych zwrotów i pełnej identyfikowalności w raportach.
Spory są rozwiązywane za pośrednictwem banków/dostawców usług płatniczych i przepisów pomocniczych; lay SLA i zbieranie dowodów (dziennik zamówienia, dostawa, korespondencja).

9) Integracja handlowców: Opcje

1. Statyczny PayID

Zacznij szybko, minimalny rozwój.
Ryzyko: czynnik ludzki (wprowadzenie kwoty/komentarza), słabsza analiza.

2. Dynamiczny QR/deeplink

Generowanie na zamówienie: stała kwota, Id, przekazy pieniężne.
Lepszy zwiad na zamówienie, mniej błędów, większa konwersja.

3. Żądanie zapłaty

„Faktura” od handlowca → potwierdzenie od płatnika.
Przydatne do fakturowania, B2B i usług o zmiennej kwocie.

4. PayTo (e-mandaty)

Abonamenty/opłaty cykliczne; płatnik zarządza mandatem w swoim banku.
Potrzebujemy ekranów zgody, zarządzania ograniczeniami, powiadomień przed umorzeniami.

• Haki stanu sieci (sukces/awaria/czas oczekiwania), powtarzane sondaże przez backoff.
• Tablica Idempotence (klucz zapytania na temat Id +).
• Uzgodnienie przez UTR/ Id/time/amount.
• Zwrot API i procedury ODR.
• Monitorowanie banku/PSP SLA (opóźnienie, sukces, kody błędów).

10) Uzgodnienie i sprawozdawczość (ISO 20022, UTR)

UTR (niepowtarzalny identyfikator transferu) - główny klucz pojednania; Zachowaj zarówno pierwotną płatność, jak i zwrot.
Użyj pól przypisania/przekazu ISO 20022 w odniesieniu do Id, koszyka, customerRef.
Konfiguracja dziennego auto-recona i okresowego pełnego zwiadu.
Raporty PSP: transakcje, statusy, bilety PayTo, zwroty, odchylenia.

11) Taryfy i koszty

W przypadku NPP/PayID nie ma klasycznego MDR, jak w systemach kart, jednak istnieją opłaty dostawcy za nabycie modułów PayTo, raportowania, pakietów SLA.
Weź pod uwagę koszty wsparcia/sporów, zwalczania oszustw, generowania QR i hostingu stron deeplink.

12) Opcje offline i QR

Prezentowany przez handlowca QR (dynamiczny): optymalny dla POS/realizacji transakcji; ilość i metadane są chronione kodem.
Statyczny QR: koduje system PayID bez kwoty; Wprowadź kwotę ręcznie.
Drukowanie/sprawdzanie na tablicy: dozwolone dla małych przedsiębiorstw, ale gorsze dla pojednania.

13) Zgodność, AML/CTF i poufność

Zgodność z AML/CTF (AUSTRAC), przechowywanie dziennika transakcji/biletów, poziomy KYC w PSP.
Stosowanie kontroli sankcji/oszustw na poziomie PSP, zasad prędkości, monitorowania anomalii.
Przetwarzanie danych PayID zgodnie z zasadami minimalizacji; Pokaż tylko to, co jest wymagane do UX i audytu.

14) Cechy wysokiego ryzyka (w tym iGaming)

Banki/dostawcy usług płatniczych w Australii mogą ograniczać poszczególne kategorie do własnej polityki ryzyka.
Spodziewaj się obniżonych limitów, wzmocnionego KYC i dodatkowych analiz transakcji.
Zaplanuj alternatywne szyny dla depozytów/spłat i jasny proces zwrotu.

15) Architektura usług NPP/PayID Gateway

Interfejs API: " Intent", "gener," DynamicQR "," ToPay "," PayToMandate "," Zwrot "," reconcile "," webhook ".
Niezawodność: Przekładać wykładniczo, idempotencja, deduplikacja zdarzeń.
Obserwowalność: wskaźniki (sukces/niepowodzenia/opóźnienia), ślady, wpisy dotyczące banków SLA.
Bezpieczeństwo: HMAC podpis haków internetowych, permlist IP, rotacja tajemnic, dziennik audytu.
Dane: poszczególne katalogi limitów przez banki/kanały, statusy mandatu PayTo, karta UTR.

16) Lista kontrolna wyjściowa

1. Pobierz handlowca PayID (lub pulę PayID) z banku/PSP.
2. Wybierz strumień: dynamiczny QR/deeplink, Request-to-Pay i/lub PayTo.
3. Wdrożyć haczyki internetowe, idempotencję i stół biletowy.
4. Włącz zwiad zorientowany na UTR (codziennie + pełny), alerty przez błędne uzgodnienie.
5. Uruchom przepływ zwrotu (pełny/częściowy), dzienniki ODR.
6. Dodaj ekrany limitu UX, podgląd nazwy PayID, zrozumiałe błędy.
7. Skonfiguruj deski kontrolne i rozdzielcze SLA.
8. Przeprowadzaj testy typu end-to-end z różnymi bankami emitującymi i scenariuszami PayTo.

Wznów streszczenie

W przypadku płatności jednorazowych postaw na dynamiczne QR/deeplink z bogatymi metadanymi.
W przypadku subskrypcji i płatności cyklicznych korzystaj z biletów PayTo z przejrzystym zarządzaniem UX.
Nie ograniczaj kodu twardego: zachowaj konfiguracje banku/PSP i aktualizuj.
Budowanie procesu wokół uzgadniania UTR, szczegółowe rejestrowanie i ostrzeganie przez SLA.