PayID Australia: NPP flows

1) Context: NPP and PayID

NPP (New Payments Platform) - Australia's national instant payment infrastructure (24/7/365) with real-time settlements and a rich ISO 20022 message. PayID is an addressing layer on top of NPP, which allows you to pay not by BSB/Account, but by "human" alias: phone number, email, ABN/ACN or Organization ID.

• Interoperability: any NPP participants ↔ any issuing banks.
• Alias addressing: the payer sees the PayID Name before confirmation (anti-misdirection).
• Instantaneity and finality: credit on the merchant's account is displayed immediately; return - a separate operation.
• Payment data: ISO 20022 with convenient remittance (purpose of payment, orderId, etc.).

2) Members and roles

NPP/Schema Routing and Rules

Payer bank (Payer FI): client authentication, anti-fraud, sending a message.
Payee bank/acquirer (Payee FI): loan acceptance, notifications, reporting.
PSP/fintech: front-line applications, SDKs, reports and reconciliation for merchants.
Merchant: holds PayID (or bank details), generates a request/link to the payer.

3) PayIDs

Types of PayID: mobile, email, ABN/ACN, Organization ID.

• Each PayID is associated with a PayID Name that the payer sees before confirming.
• A single account can have multiple PayIDs; Cross-bank portability is supported by migration procedures.
• ABN/ACN-PayID are convenient for business: it is easier to match the company profile.

4) Basic payment flows (NPP/PayID)

P2P (push): the payer enters/scans the payee's PayID → sees the PayID Name → confirms → credit instantly.
P2M (push): the merchant publishes a PayID or issues a deeplink/QR with a pre-filled amount and metadata.
Request-to-Pay (collect): merchant initiates a request for payment; the user confirms in the banking application.

• For e-commerce, use deeplink/QR with a fixed amount and orderId.
• For offline, a static PayID is acceptable, but a dynamic QR per-order is better.

5) PayTo: e-mandates and autocommissions

• Merchant/PSP creates ticket with parameters (payer, account, limits, frequency, description).
• The payer authorizes the mandate in its banking application.
• Further write-offs are carried out automatically within the terms of the mandate without every-step manual authentication.
• Scenarios: subscriptions, utility/telco, regular plans, usage-based billing with ceiling.

• Show the user the ticket limits, frequency and date of the next charge.
• Keep the ticket control panel (pause/cancel/update) and web hooks about the statuses.

6) Limits and risk control

• Per-transaction/Per-day: Bank thresholds for NPP/PayID may vary and vary.
• New recipients: Reduced starting limits and/or shutter speed are often in effect.
• Categorical policies: individual MCCs/verticals may have tightening.
• PayTo tickets: limits are set in the ticket itself (amount, period, maximum write-off).

• Do not hardcode amounts - keep the limit directory and update regularly.
• In the interface, warn about possible excess and suggest splitting checks, if possible.

7) UX and Security

Confirmation of Payee-like verification: displaying PayID Name reduces the risk of recipient error.
2FA and device binding at the payer's bank at the time of authorization.
Antifraud/velocity: banks have their own rules; consider possible "soft" failures.
Transparency: check with UTR/time/amount/purpose + support contacts.
Fallback: If deeplink hasn't opened, offer PayID copying, static QR and instructions.

8) Returns and disputes

There is no Chargers in the card sense. The return is a new credit transaction from the merchant to the payer with reference to the original UTR/OrderId.
Support partial returns and full traceability in reports.
Disputes are resolved through banks/PSPs and support regulations; lay SLA and evidence collection (order log, delivery, correspondence).

9) Merchant Integration: Options

1. Static PayID

Start quickly, minimum development.
Risks: human factor (entering amount/comment), weaker analytics.

2. Dynamic QR/deeplink

Generation to order: fixed amount, orderId, remittance.
Better per-order recon, fewer errors, higher conversion.

3. Request-to-Pay

The "invoice" from the merchant → confirmation from the payer.
Useful for invoicing, B2B, and variable amount services.

4. PayTo (e-mandates)

Subscriptions/recurring charges; the payer manages the mandate at their bank.
We need consent screens, limit management, notifications before write-offs.

• Web hooks of status (success/failure/pending), repeated polls by backoff.
• Idempotency table (orderId + query key).
• Reconciliation by UTR/OrderId/time/amount.
• Refund APIs and ODR procedures.
• Bank/PSP SLA monitoring (latency, success, error codes).

10) Reconciliation and Reporting (ISO 20022, UTR)

UTR (unique transfer identifier) - main reconciliation key; Keep both the original payment and the return.
Use ISO 20022 assignment/remittance fields for orderId, cart, customerRef.
Configure daily auto-recon and periodic full-recon.
PSP reports: transactions, statuses, PayTo tickets, returns, deviations.

11) Tariffs and costs

For NPP/PayID there is no classic MDR as in card schemes, however, there are provider fees for acquiring, PayTo modules, reporting, SLA packages.
Consider the costs of support/disputes, anti-fraud, QR generation and deeplink page hosting.

12) Offline options and QR

Merchant-presented QR (dynamic): optimal for POS/checkout; amount and metadata are protected into code.
Static QR: encodes PayID without amount; Enter the amount manually.
Print-on-check/on the plate: allowed for small businesses, but worse for reconciliation.

13) Compliance, AML/CTF and Confidentiality

Comply with AML/CTF (AUSTRAC), transaction/ticket log storage, KYC levels in PSP.
Apply sanction/fraud screening at the PSP level, Velocity rules, anomaly monitoring.
Process PayID data according to minimization principles; Show only what is required for UX and auditing.

14) High-risk features (including iGaming)

Banks/PSPs in Australia may restrict individual categories on their own risk policies.
Expect reduced limits, strengthened KYC and additional transaction analytics.
Plan alternative rails for deposits/repayments and a clear returns process.

15) NPP/PayID Gateway service architecture

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Reliability: Retray exponentially, idempotency, event deduplication.
Observability: metrics (success/failures/latency), traces, alerts on SLA banks.
Security: HMAC signature of web hooks, allowlist IP, rotation of secrets, audit log.
Data: individual directories of limits by banks/channels, PayTo mandate statuses, UTR card.

16) Output checklist

1. Get merchant PayID (or PayID pool) from bank/PSP.
2. Select a stream: dynamic QR/deeplink, Request-to-Pay and/or PayTo.
3. Implement web hooks, idempotence and a ticket table.
4. Enable UTR-oriented recon (daily + full), alerts by misalignment.
5. Run Refund flow (full/partial), ODR logs.
6. Add UX limit screens, PayID Name preview, understandable errors.
7. Set up SLA monitoring and provider dashboards.
8. Conduct end-to-end tests with different issuing banks and PayTo scenarios.

Resume Summary

For one-time payments, bet on dynamic QR/deeplink with rich metadata.
For subscriptions and recurring payments, use PayTo tickets with transparent UX management.
Do not hard code limits: keep bank/PSP configs and update.
Build a process around UTR reconciliation, detailed logging and alerting by SLA.