PayID Avstraliya: NPP axınları

1) Kontekst: NPP və PayID

NPP (New Payments Platform) - real vaxt hesablamaları və zəngin ISO 20022 mesajı ilə Avstraliyanın milli ani ödəniş infrastrukturu (24/7/365). PayID - BSB/Account ilə deyil, «insan» aliası ilə: telefon nömrəsi, email, ABN/ACN və ya Orqanizasiya ID ilə ödəməyə imkan verən NPP üzərindəki ünvan təbəqəsidir.

• İnteraktivlik: hər hansı bir NPP üzvü hər hansı bir bank-emitent.
• Alias ünvanı: ödəyici təsdiqlənmədən əvvəl PayID Name-ni görür (anti-misdirection).
• Anlıq və son: alıcı hesabında kredit dərhal göstərilir; geri qaytarılması - ayrıca əməliyyat.
• Ödəniş məlumatları: ISO 20022 (ödəniş təyinatı, orderId və s.).

2) İştirakçılar və rollar

NPP/sxem: marşrutlaşdırma və qaydalar.
Ödəyicinin bankı (Payer FI): müştərinin identifikasiyası, antifrod, mesaj göndərilməsi.
Alıcının/ekvayerin bankı (Payee FI): kreditin qəbulu, bildirişlər, hesabatlar.
PSP/fintech: ön proqramlar, SDK, hesabatlar və merchants üçün reconciliation.
Merchant: PayID (və ya bank rekvizitləri) saxlayır, ödəyiciyə sorğu/link yaradır.

3) PayID identifikatorları

PayID növləri: mobil, email, ABN/ACN, Organization ID.

• Hər PayID təsdiqlənmədən əvvəl ödəyicinin gördüyü PayID Name ilə müqayisə olunur.
• Bir hesabda bir neçə PayID ola bilər; banklar arasında dözümlülük miqrasiya prosedurları ilə dəstəklənir.
• ABN/ACN-PayID biznes üçün rahatdır: şirkətin profilinə uyğun olmaq daha asandır.

4) Əsas ödəniş axını (NPP/PayID)

P2P (push): ödəyici daxil/alıcının PayID skan → görür PayID Name → təsdiq → dərhal kredit.
P2M (push): satıcı PayID-ni dərc edir və ya əvvəlcədən doldurulmuş məbləğ və metadata ilə deeplink/QR verir.
Request-to-Pay (collect): alıcı ödəniş sorğusunu başlatır; istifadəçi bank tətbiqində təsdiqləyir.

• E-ticarət üçün sabit məbləğ və orderId ilə deeplink/QR istifadə edin.
• Oflayn üçün statik PayID, lakin daha yaxşı - dinamik QR per-order.

5) PayTo: e-mandates və avtomatik yazılar

• Merchant/PSP parametrləri (ödəyici, hesab, limitlər, dövrilik, təsvir) ilə mandat yaradır.
• Ödəyici mandatı öz bank tətbiqində təsdiqləyir.
• Sonra silinmə avtomatik olaraq mandat şərtləri çərçivəsində hər bir əsaslı əl autentifikasiyası olmadan həyata keçirilir.
• Ssenarilər: abunə, kommunal/telko, müntəzəm planlar, tavan ilə usage-based billing.

• İstifadəçiyə mandat limitlərini, tezliyi və növbəti silinmə tarixini göstərin.
• Mandat idarəetmə panelini (pause/cancel/update) və status veb-hook saxlayın.

6) Limitlər və risk nəzarəti

• Per-transaction/Per-day: NPP/PayID üçün bank həddi dəyişə və dəyişə bilər.
• Yeni alıcılar: tez-tez azaldılmış başlanğıc limitləri və/və ya davamlılıq var.
• Kateqoriya siyasətləri: ayrı-ayrı MCC/şaquli sərtləşdirilmiş ola bilər.
• PayTo mandatları: limitlər mandatın özündə təyin olunur (məbləğ, dövr, maksimum silinmə).

• Məbləğləri sərtləşdirməyin - limitlər kitabçasını saxlayın və müntəzəm olaraq yeniləyin.
• Interfeysdə mümkün artım barədə xəbərdarlıq edin və icazə verildiyi təqdirdə çeklərin parçalanmasını təklif edin.

7) UX və təhlükəsizlik

Confirmation of Payee oxşar yoxlama: PayID Name göstərilməsi alıcının səhv riskini azaldır.
Avtorizasiya zamanı ödəyicinin bankında 2FA və device binding.
Antifrod/velocity: bankların öz qaydaları var; mümkün «yumşaq» uğursuzluqları nəzərə alın.
Şəffaflıq: UTR/vaxt/məbləğ/təyinat + əlaqə dəstəyi ilə çek.
Fallback: deeplink açılmasa, PayID kopyasını, statik QR və təlimatları təklif edin.

8) Qaytarmalar və mübahisələr

Charjback kart mənasında yoxdur. Geri qaytarma - orijinal UTR/OrderId-ə istinad edərək alıcıdan ödəyiciyə yeni kredit əməliyyatıdır.
Hesabatlarda qismən geri dönüş və tam izlənilebilirliyi saxlayın.
Mübahisələr banklar/PSP və dəstək qaydaları vasitəsilə həll edilir; SLA və dəlil toplamaq (sifariş log, çatdırılma, yazışma).

9) Merchant inteqrasiyası: variantları

1. Statik PayID

Sürətli başlanğıc, minimum inkişaf.
Risklər: insan faktoru (məbləğin daxil edilməsi/şərh), analitikadan daha zəifdir.

2. Dinamik QR/deeplink

Sifariş Generation: sabit məbləğ, orderId, remittens.
Ən yaxşı per-order recon, daha az səhv, yuxarıda dönüşüm.

3. Request-to-Pay

Alıcıdan «hesab» → ödəyicidən təsdiq.
İnvoysinq, B2B və dəyişən məbləğli xidmətlər üçün əlverişlidir.

4. PayTo (e-mandates)

Abunə/müntəzəm silinmə; ödəyici öz bankında mandatı idarə edir.
Razılıq ekranları, limitlərin idarə edilməsi, silinmədən əvvəl bildirişlər lazımdır.

• Status Web Hook (success/failure/pending), backoff üzrə təkrar sorğular.
• İdempotentlik cədvəli (orderId + sorğu açarı).
• UTR/OrderId/vaxt/məbləğ üzrə Reconciliation.
• Refund API və ODR prosedurları.
• Bankların SLA/PSP monitorinqi (gizlilik, uğur, səhv kodları).

10) Yoxlama və hesabat (ISO 20022, UTR)

UTR (unikal tərcümə identifikatoru) - əsas yoxlama açarı; həm ilkin ödənişdə, həm də geri qaytarmada saxlayın.
orderId, səbət, customerRef üçün ISO 20022 təyinat/remittens sahələrindən istifadə edin.
daily auto-recon (əməliyyat) və periodik full-recon (maliyyə) konfiqurasiya.
PSP hesabatları: əməliyyatlar, statuslar, PayTo mandatları, geri qaytarmalar, sapmalar.

11) Tariflər və xərclər

NPP/PayID üçün kart sxemlərində olduğu kimi klassik MDR yoxdur, lakin provayder ekvayrinq haqları, PayTo modulları, hesabatlar, SLA paketləri var.
Dəstək/disputlar, antifrod, QR yaradılması və deeplink səhifə hostinq xərclərini nəzərə alın.

12) Offline variantları və QR

Merchant-presented QR (dinamik): POS/kassa üçün optimaldır; məbləğ və metadata kodda tikilir.
Statik QR: məbləğsiz PayID kodu; məbləğ əl ilə daxil edilir.
Çap-on-çek/lövhədə: kiçik biznes üçün icazə verilir, lakin müqayisə baxımından daha pis.

13) Komplayens, AML/CTF və məxfilik

AML/CTF (AUSTRAC) tələblərinə riayət edin, əməliyyat log/mandat saxlama, PSP-də KYC səviyyələri.
PSP, Velocity qaydaları, anomaliyaların monitorinqi səviyyəsində sanksiya/frod-skrininq tətbiq edin.
PayID məlumatlarını minimallaşdırma prinsiplərinə uyğun emal edin; UX və audit üçün lazım olanı göstərin.

14) Yüksək risk xüsusiyyətləri (iGaming daxil olmaqla)

Avstraliyadakı banklar/PSP öz risk siyasətlərinə görə müəyyən kateqoriyaları məhdudlaşdıra bilər.
Azaldılmış limitləri, gücləndirilmiş KYC və əlavə əməliyyat analitikasını gözləyin.
Depozitlər/ödənişlər və dəqiq geri qaytarma prosesi üçün alternativ relslər planlaşdırın.

15) «NPP/PayID Gateway» xidmətinin arxitekturası

API: `createPaymentIntent`, `generateDynamicQR`, `requestToPay`, `createPayToMandate`, `refund`, `reconcile`, `webhook`.
Etibarlılıq: eksponent retrasiyalar, idempotentlik, hadisələrin deduplikasiyası.
Observability: SLA bankları üzrə metriklər (uğur/uğursuzluq/gizli), izlər, alertlər.
Təhlükəsizlik: HMAC imzası web hook, allowlist IP, sirlərin rotasiyası, audit jurnalı.
Məlumat: banklar/kanallar üzrə ayrı-ayrı limit məlumat kitabçaları, PayTo-mandat statusları, UTR-kart.

16) Hasilat çek siyahısı

1. Bankdan/PSP-dən Merchant PayID (və ya PayID hovuzu) alın.
2. Bir axın seçin: dinamik QR/deeplink, Request-to-Pay və/və ya PayTo.
3. Veb-hook, idempotent və mandat cədvəlini həyata keçirmək.
4. UTR yönümlü recon (daily + full), rasinxronlara görə alertləri daxil edin.
5. Refund-flow (tam/qismən), ODR jurnallarını işə salın.
6. Limitlərin UX ekranlarını əlavə edin, PayID Name preview, başa düşülən səhvlər.
7. SLA monitorinqini və provayder dashboardlarını qurun.
8. Müxtəlif emitent banklarla və PayTo ssenariləri ilə end-to-end testlər aparmaq.

Xülasə

Birdəfəlik ödənişlər üçün zəngin metadata malik dinamik QR/deeplink-ə bahis edin.
Abunə və müntəzəm ödənişlər üçün şəffaf UX idarəetmə ilə PayTo mandatları istifadə edin.
Limitləri sərt kodlamayın: banklarda/PSP-də konfiqləri saxlayın və yeniləyin.
SLA ilə UTR-yoxlama, ətraflı loging və alerting ətrafında prosesi qurun.