PayID Австралія: NPP-потоки

1) Контекст: NPP и PayID

NPP (New Payments Platform) - національна миттєва платіжна інфраструктура Австралії (24/7/365) з розрахунками в режимі реального часу і багатим ISO 20022-повідомленням. PayID - шар адресації поверх NPP, який дозволяє платити не по BSB/Account, а по «людському» аліасу: номер телефону, email, ABN/ACN або Organisation ID.

• Інтероперабельність: будь-які учасники NPP ↔ будь-які банки-емітенти.
• Адресація по аліасу: платник бачить PayID Name до підтвердження (anti-misdirection).
• Миттєвість і фінальність: кредит на рахунку мерчанта відображається відразу; повернення - окремою операцією.
• Дані оплати: ISO 20022 зі зручним ремітенсом (призначення платежу, orderId тощо).

2) Учасники та ролі

NPP/схема: маршрутизація і правила.
Банк платника (Payer FI): автентифікація клієнта, антифрод, відправка повідомлення.
Банк одержувача/еквайєр (Payee FI): прийом кредиту, повідомлення, звітність.
PSP/фінтех: фронтові додатки, SDK, звіти і reconciliation для мерчантів.
Мерчант: тримає PayID (або банківські реквізити), генерує платнику запит/посилання.

3) Ідентифікатори PayID

Типи PayID: мобільний, email, ABN/ACN, Organisation ID.

• Кожному PayID зіставлений PayID Name, який платник бачить перед підтвердженням.
• Один рахунок може мати кілька PayID; переносимість між банками підтримується процедурами міграції.
• Для бізнесу зручні ABN/ACN-PayID: легше відповідати профілю компанії.

4) Базові потоки оплати (NPP/PayID)

P2P (push): платник вводить/сканує PayID одержувача → бачить PayID Name → підтверджує → кредит миттєво.
P2M (push): мерчант публікує PayID або видає deeplink/QR з передзаповненою сумою і метаданими.
Request-to-Pay (collect): мерчант ініціює запит на оплату; користувач підтверджує в банківському додатку.

• Для e-commerce використовуйте deeplink/QR з фіксованою сумою і orderId.
• Для офлайну припустимо статичний PayID, але краще - динамічний QR per-order.

5) PayTo: e-mandates і автосписання

• Мерчант/PSP створює мандат з параметрами (платник, рахунок, ліміти, періодичність, опис).
• Платник авторизує мандат у своєму банківському додатку.
• Далі списання проходять автоматично в рамках умов мандата без кожної азової ручної автентифікації.
• Сценарії: підписки, комунальні/телко, регулярні плани, usage-based білінг зі стелею.

• Показуйте користувачеві ліміти мандата, частоту і дату наступного списання.
• Тримайте панель управління мандатами (pause/cancel/update) і веб-хуки про статуси.

6) Ліміти та ризик-контроль

• Per-transaction / Per-day: банківські пороги для NPP/PayID можуть відрізнятися і змінюватися.
• Нові одержувачі: часто діють знижені стартові ліміти та/або витримка.
• Категорійні політики: окремі МСС/вертикалі можуть мати жорсткості.
• PayTo-мандати: ліміти задаються в самому мандаті (сума, період, макс. списання).

• Не хардкодьте суми - зберігайте довідник лімітів і регулярно актуалізуйте.
• В інтерфейсі попереджайте про можливе перевищення і пропонуйте дроблення чеків, якщо це допустимо.

7) UX і безпека

Confirmation of Payee-подібна перевірка: показ PayID Name зменшує ризик помилки адресата.
2FA і device binding у банку платника на момент авторизації.
Антифрод/velocity: у банків власні правила; враховуйте можливі «м'які» відмови.
Прозорість: чек з UTR/часом/сумою/призначенням + контакти підтримки.
Fallback: якщо deeplink не відкрився, запропонуйте копіювання PayID, статичний QR та інструкції.

8) Повернення і диспути

Чарджбека в картковому сенсі немає. Повернення - це нова кредитова транзакція від мерчанта платнику з посиланням на вихідний UTR/OrderId.
Підтримуйте часткові повернення і повну трассируемость в звітах.
Диспути вирішуються через банки/PSP і регламенти підтримки; закладайте SLA і збір доказів (лог замовлення, доставка, листування).

9) Інтеграція мерчанта: варіанти

1. Статичний PayID

Швидко стартувати, мінімум розробки.
Ризики: людський фактор (введення суми/коментаря), слабкіше аналітика.

2. Динамічний QR/deeplink

Генерація на замовлення: фіксована сума, orderId, реміттенс.
Кращий per-order recon, менше помилок, вище конверсія.

3. Request-to-Pay

«Рахунок» від мерчанта → підтвердження у платника.
Зручно для інвойсингу, B2B і послуг зі змінною сумою.

4. PayTo (e-mandates)

Підписки/регулярні списання; платник управляє мандатом у своєму банку.
Потрібні екрани згоди, управління лімітами, повідомлення перед списаннями.

• Веб-хуки статусів (success/failure/pending), повторні опитування по backoff.
• Таблиця ідемпотентності (orderId + ключ запиту).
• Reconciliation по UTR/OrderId/часу/сумі.
• Refund API і ODR-процедури.
• Моніторинг SLA банків/PSP (латентність, успіх, коди помилок).

10) Звірка та звітність (ISO 20022, UTR)

UTR (унікальний ідентифікатор перекладу) - головний ключ звірки; зберігайте і на початковій оплаті, і на поверненні.
Використовуйте поля призначення/реміттенсу ISO 20022 для orderId, кошика, customerRef.
Налаштуйте daily auto-recon (операційний) і періодичний full-recon (фінансовий).
Звіти PSP: транзакції, статуси, мандати PayTo, повернення, відхилення.

11) Тарифи і витрати

Для NPP/PayID немає класичного MDR як в карт-схемах, проте є провайдерські збори за еквайринг, модулі PayTo, звітність, SLA-пакети.
Враховуйте витрати на підтримку/диспути, антифрод, генерацію QR і хостинг deeplink-сторінок.

12) Оффлайн-варіанти і QR

Merchant-presented QR (динамічний): оптимальний для POS/каси; сума і метадані зашиті в код.
Статичний QR: кодує PayID без суми; сума вводиться вручну.
Друк-на-чеку/на табличці: допускається для малого бізнесу, але гірше по звірці.

13) Комплаєнс, AML/CTF і конфіденційність

Дотримуйтесь вимог AML/CTF (AUSTRAC), зберігання логів транзакцій/мандатів, KYC рівні в PSP.
Застосовуйте санкційний/фрод-скринінг на рівні PSP, Velocity-правила, моніторинг аномалій.
Дані PayID обробляйте за принципами мінімізації; показуйте тільки те, що потрібно для UX і аудиту.

14) Особливості high-risk (включаючи iGaming)

Банки/PSP в Австралії можуть обмежувати окремі категорії за власними політиками ризику.
Очікуйте знижених лімітів, посиленого KYC і додаткової аналітики транзакцій.
Плануйте альтернативні рейки для депозитів/виплат і чіткий процес повернень.

15) Архітектура сервісу «NPP/PayID Gateway»

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Надійність: ретраї по експоненті, ідемпотентність, дедуплікація подій.
Observability: метрики (успіх/відмови/латентність), трасування, алерти по SLA банків.
Безпека: HMAC підпис веб-хуків, allowlist IP, ротація секретів, журнал аудиту.
Дані: окремі довідники лімітів по банках/каналах, статуси PayTo-мандатів, UTR-картка.

16) Чек-лист виведення в прод

1. Отримати мерчантський PayID (або пул PayID) у банку/PSP.
2. Вибрати потік: динамічний QR/deeplink, Request-to-Pay і/або PayTo.
3. Реалізувати веб-хуки, ідемпотентність і таблицю мандатів.
4. Включити UTR-орієнтований recon (daily + full), алерти по розсинхронах.
5. Запустити Refund-флоу (повний/частковий), журнали ODR.
6. Додати UX-екрани лімітів, прев'ю PayID Name, зрозумілі помилки.
7. Налаштувати моніторинг SLA і провайдерські дашборди.
8. Провести end-to-end тести з різними банками-емітентами і сценаріями PayTo.

Резюме

Для одноразових оплат робіть ставку на динамічний QR/deeplink з багатими метаданими.
Для підписок і регулярних платежів використовуйте PayTo-мандати з прозорим UX управління.
Не жорстко кодуйте ліміти: тримайте конфіги по банках/PSP і оновлюйте.
Будуйте процес навколо UTR-звірки, докладного логування і alerting по SLA.