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排序构建过程。