PayID Australie : flux NPP

1) Contexte : NPP et PayID

NPP (New Payments Platform) est l'infrastructure nationale de paiement instantané de l'Australie (24/7/365) avec des paiements en temps réel et un riche message ISO 20022. PayID est une couche d'adressage au-dessus du NPP qui vous permet de payer non pas par BSB/Compte, mais par alias « humain » : numéro de téléphone, email, ABN/ACN ou Organisation ID.

• Interopérabilité : tous les participants au PNP ↔ toutes les banques émettrices.
• Adressage par alias : le payeur voit PayID Name avant la confirmation (anti-misdirection).
• Instantanéité et finalité : le crédit sur le compte du merchant est affiché immédiatement ; retour - par une opération distincte.
• Données de paiement : ISO 20022 avec remittense commode (destination du paiement, orderId, etc.).

2) Participants et rôles

NPP/schéma : routage et règles.
Banque du payeur (Payer FI) : authentification du client, antifrod, envoi du message.
Banque bénéficiaire/acquéreur (Payee FI) : acceptation de crédit, notifications, rapports.
PSP/fintech : applications de première ligne, SDK, rapports et reconnaissance pour les merchants.
Merchant : détient PayID (ou coordonnées bancaires), génère une demande/lien au payeur.

3) Identifiants PayID

Types de PayID : mobile, email, ABN/ACN, Organisation ID.

• Chaque nom PayID est mappé par le nom PayID que le payeur voit avant la confirmation.
• Un compte peut avoir plusieurs PayID ; la portabilité entre banques est maintenue par les procédures de migration.
• L'ABN/ACN-PayID est pratique pour les entreprises : il est plus facile de s'adapter au profil de l'entreprise.

4) Flux de paiement de base (NPP/PayID)

P2P (push) : le payeur introduit/scanne PayID le destinataire → voit PayID Name → confirme → le crédit instantanément.
P2M (push) : le merchant publie un PayID ou émet un deeplink/QR avec un montant et des métadonnées pré-remplis.
Request-to-Pay (collect) : le merchant lance une demande de paiement ; l'utilisateur confirme dans l'application bancaire.

• Pour le commerce électronique, utilisez deeplink/QR avec une somme fixe et orderId.
• Pour l'offline, admettez un PayID statique, mais mieux, un QR dynamique par ordre.

5) PayTo : e-mandates et auto-space

• Merchant/PSP crée un mandat avec des paramètres (payeur, compte, limites, fréquence, description).
• Le payeur autorise le mandat dans sa demande bancaire.
• Ensuite, les radiations sont automatiques dans le cadre du mandat sans authentification manuelle quotidienne.
• Scénarios : abonnements, services publics/télévision, plans réguliers, utilisation-based facturation avec plafond.

• Montrez à l'utilisateur les limites de mandat, la fréquence et la date du prochain prélèvement.
• Gardez le panneau de contrôle des mandats (pause/cancel/update) et le Web hooks sur les statuts.

6) Limites et contrôle des risques

• Per-transaction/Per-day : les seuils bancaires pour NPP/PayID peuvent varier et changer.
• Nouveaux bénéficiaires : les limites de départ et/ou de vitesse d'obturation sont souvent réduites.
• Politiques par catégories : Les administrateurs auxiliaires/verticaux individuels peuvent être durcis.
• Mandats PayTo : les limites sont fixées dans le mandat lui-même (montant, période, débits maximum).

• Ne hardcodez pas les montants - gardez le manuel des limites et mettez à jour régulièrement.
• Dans l'interface, avertissez-vous d'un éventuel dépassement et proposez l'écrasement des chèques si cela est acceptable.

7) UX et sécurité

Vérification de la confirmation de Payee : l'affichage de PayID Name réduit le risque d'erreur de destination.
2FA et binding d'appareils à la banque du payeur au moment de l'autorisation.
Antifrod/velocity : les banques ont leurs propres règles ; prendre en compte les éventuels refus « doux ».
Transparence : chèque avec UTR/temps/montant/destination + contacts de soutien.
Fallback : si deeplink n'a pas ouvert, suggérez une copie PayID, un QR statique et des instructions.

8) Retours et disputes

Il n'y a pas de carte. La déclaration est une nouvelle transaction de crédit du merchant au payeur avec une référence à l'UTR/OrderId d'origine.
Maintenez les retours partiels et la traçabilité complète dans les rapports.
Les disputes sont réglées par le biais des banques/PSP et des règlements de soutien ; placez un SLA et collectez des preuves (carnet de commande, livraison, correspondance).

9) Intégration du merchant : options

1. PayID statique

Démarrage rapide, minimum de développement.
Risques : facteur humain (entrée de somme/commentaire), plus faible que l'analyste.

2. Dynamique QR/deeplink

Génération sur mesure : montant fixe, orderId, remittens.
Meilleur per-order recon, moins d'erreurs, conversion supérieure.

3. Request-to-Pay

Le « compte » du merchant → la confirmation du payeur.
Pratique pour la facturation, le B2B et les services à somme variable.

4. PayTo (e-mandates)

Abonnements/débits réguliers ; le payeur gère le mandat dans sa banque.
Vous avez besoin d'écrans de consentement, de gestion des limites, de notifications avant les débits.

• Web hooks de statut (success/failure/pending), des sondages répétés sur backoff.
• Table d'idempotence (orderId + clé de requête).
• Reconnaissance par UTR/OrderID/temps/somme.
• Refund API et procédures ODR.
• Surveillance des banques SLA/PSP (latence, succès, codes d'erreur).

10) Rapprochement et établissement de rapports (ISO 20022, UTR)

UTR (ID de traduction unique) - clé de rapprochement principale ; conservez à la fois sur le paiement initial et sur le remboursement.
Utilisez les champs de destination/remittente ISO 20022 pour orderId, panier, customerRef.
Configurez daily auto-recon (opérationnel) et périodique full-recon (financier).
Rapports PSP : transactions, statuts, mandats PayTo, retours, refus.

11) Tarifs et coûts

Pour NPP/PayID, il n'y a pas de MDR classique comme dans les cartes, mais il y a des frais d'acquisition, des modules PayTo, des rapports, des paquets SLA.
Tenez compte des coûts de support/disputes, antifrod, génération de QR et hébergement de pages deeplink.

12) Options hors ligne et QR

Merchant-presented QR (dynamique) : optimal pour POS/caisse ; la somme et les métadonnées sont cousues dans le code.
QR statique : code PayID sans montant ; le montant est saisi manuellement.
Imprimer-sur-chèque/sur un panneau : autorisé pour les petites entreprises, mais pire par le rapprochement.

13) Conformité, AML/CTF et confidentialité

Respecter les exigences de l'AML/CTF (AUSTRAC), stocker les logs de transaction/de mandat, niveaux KYC dans le PSP.
Appliquer le dépistage des sanctions/frod au niveau de la PSP, des règles Velocity, de la surveillance des anomalies.
Traiter les données PayID selon les principes de minimisation ; montrez seulement ce qui est requis pour l'UX et l'audit.

14) Caractéristiques de risque élevé (y compris iGaming)

Les banques/PSP en Australie peuvent limiter certaines catégories selon leurs propres politiques de risque.
Attendez-vous à des limites réduites, un KYC renforcé et des analyses de transactions supplémentaires.
Planifier d'autres rails pour les dépôts/paiements et un processus de remboursement clair.

15) L'architecture du service « NPP/PayID Gateway »

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Fiabilité : retraits par exposant, idempotence, déduplication des événements.
Observability : métriques (succès/échecs/latence), traçabilité, alertes sur les SLA des banques.
Sécurité : HMAC signature Web hooks, IP allowlist, rotation des secrets, journal d'audit.
Données : guides des limites par banque/canal, statuts des mandats PayTo, carte UTR.

16) Chèque-liste de sortie dans la prod

1. Obtenez un ID (ou un pool d'ID) merchant auprès de la banque/PSP.
2. Sélectionnez un flux : QR/deplink dynamique, Request-to-Pay et/ou PayTo.
3. Mettez en œuvre le Web, l'idempotence et la table des mandats.
4. Activer UTR recon orienté (daily + full), alertes par dissynchrones.
5. Lancez Refund-flow (complet/partiel), logs ODR.
6. Ajouter des écrans UX limites, prévisualiser PayID Name, erreurs compréhensibles.
7. Configurez la surveillance SLA et les dashboards fournisseurs.
8. Effectuer des tests end-to-end avec différentes banques émettrices et scénarios PayTo.

Résumé

Pour les paiements jetables, pariez sur un QR/deeplink dynamique avec des métadonnées riches.
Pour les abonnements et les paiements récurrents, utilisez les mandats PayTo avec gestion UX transparente.
N'encodez pas rigidement les limites : gardez les configs sur les banques/PSP et mettez à jour.
Construisez le processus autour du rapprochement UTR, du logage détaillé et de l'alerting par SLA.