PayID澳大利亞：NPP流

1）上下文： NPP和PayID

NPP（新付款平臺）是澳大利亞的國家即時支付基礎設施（24/7/365），具有實時結算和豐富的ISO 20022消息。PayID是NPP頂部的尋址層，它允許您不通過BSB/Account付款，而是通過「人」alias付款：電話號碼，電子郵件，ABN/ACN或組織ID。

• 互操作性：任何NPP參與者↔任何發行銀行。
• Alias尋址：付款人在確認前看到PayID Name （anti-misdirection）。
• 即時性和最終性：立即顯示商戶帳戶中的信用；返回-一個單獨的操作。
• 付款數據：ISO 20022，帶有方便的回調（付款目的，orderId等）。

2）參與者和角色

NPP/方案：路由和規則。
付款人銀行（Payer FI）：客戶身份驗證、反欺詐、發送消息。
收款人銀行/收款人（Payee FI）：接受貸款、通知、報告。
PSP/fintech：面向商人的前線應用程序，SDK，報告和恢復。
商家：持有PayID（或銀行詳細信息）,生成付款人的請求/鏈接。

3） PayID ID

PayID類型： 移動,電子郵件,ABN/ACN, Organisation ID.

• 每個PayID都映射到付款人在確認之前看到的PayID名稱。
• 一個帳戶可能具有多個PayID；銀行之間的可移植性得到遷移程序的支持。
• ABN/ACN-PayID方便您的業務：更容易匹配您的公司配置文件。

4）基本支付流程（NPP/PayID）

P2P（推）：付款人輸入/掃描收件人的PayID →看到PayID Name →立即確認→信用。
P2M （push）：商人發布PayID或簽發deeplink/QR和預填充金額和元數據。
要求支付（收集）：商家啟動付款請求；用戶在銀行應用程序中確認。

• 對於電子商務,請使用deeplink/QR固定金額和orderId。
• 對於離線，允許靜態PayID，但最好是動態QR對訂單。

5）PayTo： 電子禮儀和賽車運動

• 商人/PSP使用參數（付款人，帳戶，限制，頻率，描述）創建任務。
• 付款人在其銀行應用程序中授權授權。
• 此外，註銷在任務規定範圍內自動進行，而無需進行手動認證。
• 情景：訂閱，公用事業/telko，定期計劃，基於用戶的上限計費。

• 向用戶顯示下一次註銷的任務限制、頻率和日期。
• 保持任務控制面板（pause/cancel/update）和關於狀態的Web hooks。

6）限制和風險控制

• 按交易/按日：NPP/PayID的銀行門檻可能會有所不同和變化。
• 新收件人：通常會降低起始限制和/或快門速度。
• 分類政策：單個初專幹事/縱向政策可能收緊。
• PayTo授權：在授權本身中設置限制（金額、期限、最大註銷）。

• 不要硬編碼金額-保存限制手冊並定期更新。
• 在界面中，警告可能超支，並在允許的情況下建議支票破碎。

7） UX和安全

Payee認證：顯示PayID名稱可降低收件人錯誤的風險。
2 FA和設備在授權時從付款人的銀行進行約束。
Antifrod/velocity：銀行有自己的規則；考慮可能的「軟」故障。
透明度：帶有UTR/時間/金額/用途+支持聯系人的支票。
Fallback：如果deeplink未打開,請提供PayID復制、靜態QR和說明。

8）退貨和付款

卡片意義上沒有沖鋒槍。退款是從商家到付款人的新信用交易，參考原始的UTR/OrderId。
支持部分退貨和報告中的完整跟蹤。
通過銀行/PSP和支持法規解決方案；書寫SLA和收集證據（訂單日誌、交付、通信）。

9）商人集成： 選項

1.靜態PayID

快速啟動,最低限度的開發。
風險：人為因素（輸入金額/評論），比分析師弱。

2.動態QR/deeplink

定制生成：固定金額,orderId, remittens。

更好的訂單記錄,更少的錯誤,以上轉換.

3.Request-to-Pay

商人的「帳戶」→付款人確認。
便於發票、B2B和可變和服務。

4.PayTo (e-mandates)

訂閱/定期註銷；付款人在銀行管理任務。
需要同意屏幕、限制管理、註銷前通知。

• 狀態的Web hocks（成功/失敗/pending），反向重復調查。
• 冪等表（orderId+查詢密鑰）。
• 根據UTR/OrderId/時間/總和進行恢復。
• Refund API和ODR過程。
• 監視銀行/PSP的SLA（潛伏期，成功，錯誤代碼）。

10）核對和報告（ISO 20022, UTR）

UTR（唯一的翻譯ID）是對賬的主鍵；保留起始付款和退款。
對於orderId、購物車、customerRef使用ISO 20022目標/重新定義字段。
配置每日自動計數（操作）和定期全計數（財務）。
PSP報告：交易、狀態、PayTo任務、退款、拒絕。

11）關稅和成本

對於NPP/PayID，卡方案中沒有經典的MDR，但是有購買費，PayTo模塊，報告，SLA套件提供商。
考慮支持/分發、防凍、QR生成和deeplink頁面托管的費用。

12）離線選項和QR

商用QR（動態）：最適合POS/收銀機；總和和元數據被保存在代碼中。
靜態QR：無和編碼PayID；手動輸入金額。
打印在支票/板上：允許小型企業，但在對賬方面更糟。

13）合規性，AML/CTF和隱私

遵守AML/CTF（AUSTRAC）要求，保留事務/任務日誌以及PSP中的KYC級別。
在PSP、Velocity規則、異常監測級別應用制裁/親屬篩選。
PayID數據按照最小化原則處理；僅顯示UX和審計所需的內容。

14）高風險功能（包括iGaming）

澳大利亞的銀行/PSP可以根據自己的風險政策限制個別類別。
預計KYC將放寬限制，並增加交易分析。
計劃備用存款/付款軌道和明確的退款流程。

15）「NPP/PayID網關」服務體系結構"

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.

可靠性：指數回溯、等效性、事件重復數據消除。
觀察力：指標（成功/故障/潛在），跟蹤，銀行的SLA差異。
安全性：HMAC簽名Web hook，allowlist IP，保密輪換，審核日誌。
數據：通過銀行/渠道選定的限額指南，PayTo授權狀態，UTR卡。

16）入口支票清單

1.從銀行/PSP獲得PayID（或PayID池）。
2.選擇線程：動態QR/deeplink、Request-to-Pay和/或PayTo。
3.實現Web Hooks、等效性和任務表。
4.啟用以UTR為中心的recon （daily+full）, alerts按不同步。
5.運行ODR日誌的Refund-flow（完整/部分）。
6.添加UX限額屏幕、PayID Name預覽、明顯錯誤。
7.設置SLA監視和提供器行車記錄儀。
8.與不同的發行銀行和PayTo腳本進行端到端測試。

二.總結

對於一次性付款，請押註具有豐富元數據的動態QR/deeplink。
要訂閱和定期付款,請使用帶有透明管理UX的PayTo任務。
不要嚴格編碼限制：按銀行/PSP保存configs並更新。
圍繞UTR核對、詳細編寫和SLA排序構建過程。