PayID Australien: NPP-Streams

1) Kontext: NPP und PayID

NPP (New Payments Platform) ist Australiens nationale Instant-Payment-Infrastruktur (24/7/365) mit Echtzeit-Berechnungen und einer reichen ISO 20022-Nachricht. PayID ist eine Adressierungsschicht über dem NPP, mit der Sie nicht mit einem BSB/Konto, sondern mit einem „menschlichen“ Alias bezahlen können: Telefonnummer, E-Mail, ABN/ACN oder Organisation ID.

• Interoperabilität: Alle NPP-Teilnehmer ↔ alle emittierenden Banken.
• Aliasadressierung: Der Zahler sieht den PayID-Namen vor der Bestätigung (Anti-Misdirection).
• Instant und Finalität: Das Guthaben auf dem Merchant-Konto wird sofort angezeigt; Rückgabe - eine separate Transaktion.
• Zahlungsdaten: ISO 20022 mit bequemen remittens (Zahlungszweck, orderId, etc.).

2) Teilnehmer und Rollen

NPP/Schema: Routing und Regeln.
Bank des Zahlers (Payer FI): Kundenauthentifizierung, Betrugsbekämpfung, Senden einer Nachricht.
Bank des Empfängers/Acquirers (Payee FI): Kreditaufnahme, Benachrichtigungen, Berichterstattung.
PSP/Fintech: Front-End-Anwendungen, SDKs, Berichte und Reconciliation für Merchants.
Merchant: hält PayID (oder Bankverbindung), generiert eine Zahlungsanfrage/Link.

3) PayIDs

Arten von PayID: Handy, E-Mail, ABN/ACN, Organisation ID.

• Jeder PayID wird ein PayID-Name zugeordnet, den der Zahler vor der Bestätigung sieht.
• Ein Konto kann mehrere PayIDs haben; die Portabilität zwischen Banken wird durch Migrationsverfahren unterstützt.
• Für Unternehmen ist ABN/ACN-PayID praktisch: Es ist einfacher, dem Firmenprofil zu entsprechen.

4) Zugrunde liegende Zahlungsströme (NPP/PayID)

P2P (Push): Der Zahler gibt die PayID des Empfängers ein/scannt sie → sieht den PayID-Namen → bestätigt → Guthaben sofort.
P2M (Push): Der Merchant veröffentlicht eine PayID oder gibt einen Deeplink/QR mit einem vorgefüllten Betrag und Metadaten aus.
Request-to-Pay (collect): Der Merchant löst eine Zahlungsaufforderung aus; der Nutzer in der Banking-App bestätigt.

• Für E-Commerce verwenden Sie deeplink/QR mit festem Betrag und orderId.
• Für Offline ist eine statische PayID zulässig, aber eine dynamische QR pro Bestellung ist besser.

5) PayTo: E-Mandate und Selbstauskunft

• Merchant/PSP erstellt ein Mandat mit Parametern (Zahler, Konto, Limits, Periodizität, Beschreibung).
• Der Zahler autorisiert das Mandat in seiner Banking-App.
• Weitere Abbuchungen erfolgen automatisch im Rahmen der Mandatsbedingungen ohne jede manuelle Authentifizierung.
• Szenarien: Abonnements, Utility/Telko, regelmäßige Pläne, nutzungsbasierte Abrechnung mit einer Obergrenze.

• Zeigen Sie dem Benutzer die Mandatslimits, die Häufigkeit und das Datum der nächsten Abbuchung an.
• Halten Sie ein Ticket-Dashboard (Pause/Abbrechen/Aktualisieren) und Web-Hooks über Status.

6) Grenzen und Risikokontrolle

• Per-Transaction/Per-Day: Die Schwellenwerte für NPP/PayID können variieren und sich ändern.
• Neue Empfänger: Oft gibt es reduzierte Startlimits und/oder Verschlusszeiten.
• Category Policies: Einzelne MCC/Verticals können Straffungen aufweisen.
• PayTo-Mandate: Die Limits werden im Mandat selbst festgelegt (Betrag, Zeitraum, max. Abbuchung).

• Keine Hardcode-Beträge - halten Sie ein Limit-Verzeichnis und aktualisieren Sie es regelmäßig.
• Warnen Sie in der Schnittstelle vor einer möglichen Überschreitung und schlagen Sie vor, Schecks zu zerkleinern, wenn dies zulässig ist.

7) UX und Sicherheit

Bestätigung von Payee-ähnliche Überprüfung: Die Anzeige von PayID Name reduziert das Risiko eines Zielfehlers.
2FA und Gerätebindung bei der Bank des Zahlers zum Zeitpunkt der Autorisierung.
Betrugsbekämpfung/Velocity: Banken haben ihre eigenen Regeln; Berücksichtigen Sie mögliche „weiche“ Fehler.
Transparenz: Scheck mit UTR/Zeit/Betrag/Termin + Support-Kontakte.
Fallback: Wenn sich Deeplink nicht geöffnet hat, bieten Sie das Kopieren von PayID, statischem QR und Anweisungen an.

8) Retouren und Dispute

Charjback im Kartensinn gibt es nicht. Eine Rendite ist eine neue Kredittransaktion von einem Händler an einen Zahler mit Bezug auf die ursprüngliche UTR/OrderId.
Pflegen Sie Teilrückgaben und vollständige Rückverfolgbarkeit in Berichten.
Streitigkeiten werden über Banken/PSPs und Unterstützungsregelungen gelöst; Legen Sie die SLA und die Beweisaufnahme (Bestellprotokoll, Versand, Korrespondenz) fest.

9) Merchant Integration: Optionen

1. Statische PayID

Schnell loslegen, minimale Entwicklung.
Risiken: menschlicher Faktor (Eingabe des Betrags/Kommentars), schwächer als Analyst.

2. Dynamische QR/Deeplink

Erzeugung nach Maß: fester Betrag, orderId, remittens.
Besseres Per-Order-Recon, weniger Fehler, höhere Conversion.

3. Request-to-Pay

„Konto“ vom Händler → Bestätigung beim Zahler.
Praktisch für Rechnungsstellung, B2B und Dienstleistungen mit variablem Betrag.

4. PayTo (e-mandates)

Abonnements/regelmäßige Abbuchungen; der Zahler verwaltet das Mandat bei seiner Bank.
Wir brauchen Zustimmungsbildschirme, Limitmanagement, Benachrichtigungen vor Abbuchungen.

• Status-Web-Hooks (Erfolg/Versagen/Anhalten), wiederholte Backoff-Umfragen.
• Idempotenztabelle (orderId + Abfrageschlüssel).
• Reconciliation durch UTR/OrderId/Zeit/Betrag.
• Refund-API und ODR-Verfahren.
• SLA-Überwachung von Banken/PSPs (Latenz, Erfolg, Fehlercodes).

10) Abstimmung und Berichterstattung (ISO 20022, UTR)

UTR (Unique Translation Identifier) - der Hauptschlüssel des Abgleichs; Bewahren Sie sowohl die ursprüngliche Zahlung als auch die Rückerstattung auf.
Verwenden Sie die ISO 20022-Zuordnungs-/Remittenfelder für orderId, cart, customerRef.
Richten Sie daily auto-recon (operativ) und periodisch full-recon (finanziell) ein.
PSP-Berichte: Transaktionen, Status, PayTo-Mandate, Retouren, Abweichungen.

11) Tarife und Kosten

Für NPP/PayID gibt es keinen klassischen MDR wie in Kartenschemata, jedoch gibt es Providergebühren für Acquiring, PayTo-Module, Reporting, SLA-Pakete.
Berücksichtigen Sie die Kosten für Support/Dispute, Betrugsbekämpfung, QR-Generierung und Hosting von Deeplink-Seiten.

12) Offline-Optionen und QR

Merchant-presented QR (dynamisch): optimal für POS/Kasse; Summe und Metadaten werden in den Code eingenäht.
Statischer QR: codiert PayID ohne Betrag; der Betrag wird manuell eingegeben.
Print-on-Check/auf dem Schild: für kleine Unternehmen zulässig, aber schlechter im Abgleich.

13) Compliance, AML/CTF und Vertraulichkeit

Erfüllen Sie die AML/CTF-Anforderungen (AUSTRAC), Transaktions-/Mandatsprotokolle, KYC-Ebenen in der PSP.
Anwendung von Sanktions-/Betrugsscreening auf PSP-Ebene, Velocity-Regeln, Anomalieüberwachung.
Verarbeiten Sie PayID-Daten nach den Grundsätzen der Minimierung; Zeigen Sie nur, was für UX und Audit erforderlich ist.

14) High-Risk-Funktionen (einschließlich iGaming)

Banken/PSPs in Australien können bestimmte Kategorien auf ihre eigenen Risikorichtlinien beschränken.
Erwarten Sie reduzierte Limits, verstärktes KYC und zusätzliche Transaktionsanalysen.
Planen Sie alternative Schienen für Einzahlungen/Auszahlungen und einen klaren Rückgabeprozess.

15) Servicearchitektur „NPP/PayID Gateway“

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Zuverlässigkeit: Retrays nach Exponenten, Idempotenz, Deduplizierung von Ereignissen.
Observability: Metriken (Erfolg/Fehler/Latenz), Traces, Alerts von SLA-Banken.
Sicherheit: HMAC Signatur Web Hooks, allowlist IP, Rotation Geheimnisse, Audit-Protokoll.
Daten: individuelle Limitverzeichnisse nach Banken/Kanälen, PayTo-Mandatsstatus, UTR-Karte.

16) Checkliste Ausgabe in prod

1. Holen Sie sich eine Merchant PayID (oder einen PayID-Pool) von einer Bank/PSP.
2. Wählen Sie einen Stream: Dynamic QR/Deeplink, Request-to-Pay und/oder PayTo.
3. Implementieren Sie Web-Hooks, Idempotenz und Mandatstabelle.
4. Aktivieren Sie UTR-orientiertes Recon (täglich + voll), Alerts für Fehlsynchronisierungen.
5. Führen Sie Refund-Flow (vollständig/teilweise), ODR-Protokolle aus.
6. Fügen Sie UX-Begrenzungsbildschirme, PayID Name-Vorschau, verständliche Fehler hinzu.
7. SLA-Überwachung und Anbieter-Dashboards einrichten.
8. Führen Sie End-to-End-Tests mit verschiedenen Emissionsbanken und PayTo-Szenarien durch.

Zusammenfassung

Für einmalige Zahlungen setzen Sie auf einen dynamischen QR/Deeplink mit reichen Metadaten.
Für Abonnements und wiederkehrende Zahlungen verwenden Sie PayTo-Mandate mit transparenter UX-Verwaltung.
Grenzen nicht fest kodieren: Halten Sie Configs für Banken/PSPs und aktualisieren Sie.
Erstellen Sie einen Prozess rund um UTR-Abstimmung, detaillierte Protokollierung und SLA-Alerting.