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 могут различаться и меняться.
• Новые получатели: часто действуют пониженные стартовые лимиты и/или выдержка.
• Категорийные политики: отдельные MCC/вертикали могут иметь ужесточения.
• 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.