PayID Avustralya: NPP akışları

1) Bağlam: NPP ve PayID

NPP (Yeni Ödemeler Platformu) - Gerçek zamanlı yerleşimler ve zengin ISO 20022 mesajı ile Avustralya'nın ulusal anında ödeme altyapısı (24/7/365). PayID, NPP'nin üstündeki bir adresleme katmanıdır ve BSB/Hesap ile değil, "insan" takma adıyla: telefon numarası, e-posta, ABN/ACN veya Kuruluş Kimliği ile ödeme yapmanızı sağlar.

• Birlikte çalışabilirlik: Herhangi bir NPP katılımcısı ↔ herhangi bir ihraç bankası.
• Alias adresleme: ödeme yapan kişi onaydan önce PayID Adını görür (yanlış yönlendirme önleme).
• Anlık ve kesinlik: tüccarın hesabındaki kredi hemen görüntülenir; dönüş - ayrı bir operasyon.
• Ödeme verileri: Uygun havale ile ISO 20022 (ödeme amacı, orderId, vb.).

2) Üyeler ve roller

NPP/Şema Yönlendirme ve Kuralları

Ödeme bankası (Payer FI): istemci kimlik doğrulaması, dolandırıcılıkla mücadele, mesaj gönderme.
Payee bank/acquirer (Payee FI): kredi kabulü, bildirimler, raporlama.
PSP/fintech: Satıcılar için ön hat uygulamaları, SDK'lar, raporlar ve mutabakat.
Satıcı: PayID'yi (veya banka bilgilerini) tutar, ödeme yapan kişiye bir istek/bağlantı oluşturur.

3) PayID'ler

PayID türleri: mobil, e-posta, ABN/ACN, Kuruluş Kimliği.

• Her PayID, ödeme yapan kişinin onaylamadan önce gördüğü bir PayID Adı ile ilişkilidir.
• Tek bir hesap birden fazla PayID'ye sahip olabilir; Bankalar arası taşınabilirlik, geçiş prosedürleri tarafından desteklenmektedir.
• ABN/ACN-PayID iş için uygundur: şirket profilini eşleştirmek daha kolaydır.

4) Temel ödeme akışları (NPP/PayID)

P2P (push): Ödeyen, alacaklının PayID'sini girer/tarar; PayID Adını görür; anında kredi onaylar.
P2M (push): Satıcı bir PayID yayınlar veya önceden doldurulmuş bir miktar ve meta veri içeren bir deeplink/QR yayınlar.
Ödeme Talebi (toplama): satıcı ödeme talebini başlatır; kullanıcı bankacılık uygulamasında onaylar.

• E-ticaret için, sabit bir miktar ve orderId ile deeplink/QR kullanın.
• Çevrimdışı için statik bir PayID kabul edilebilir, ancak sipariş başına dinamik bir QR daha iyidir.

5) PayTo: e-mandates ve otomatik gönderimler

• Satıcı/PSP parametrelerle bilet oluşturur (ödeyen, hesap, limitler, frekans, açıklama).
• Ödeyen, bankacılık uygulamasında yetkiyi yetkilendirir.
• Daha fazla yazma işlemi, her adımda manuel kimlik doğrulaması olmadan görev tanımının şartları dahilinde otomatik olarak gerçekleştirilir.
• Senaryolar: abonelikler, yardımcı program/telekomünikasyon, düzenli planlar, tavanlı kullanım tabanlı faturalandırma.

• Kullanıcıya bir sonraki ücretin bilet limitlerini, sıklığını ve tarihini gösterin.
• Bilet kontrol panelini (duraklat/iptal et/güncelle) ve durumlarla ilgili web kancalarını saklayın.

6) Limitler ve risk kontrolü

• İşlem başına/Gün başına: NPP/PayID için banka eşikleri değişebilir.
• Yeni alıcılar: Azaltılmış başlangıç limitleri ve/veya deklanşör hızı genellikle etkilidir.
• Kategorik politikalar: Bireysel MCC'ler/dikeyler sıkılaştırılabilir.
• PayTo biletleri: Limitler biletin kendisinde belirlenir (miktar, süre, maksimum yazma).

• Miktarları sabit kodlamayın - limit dizinini saklayın ve düzenli olarak güncelleyin.
• Arayüzde, olası fazlalık hakkında uyarın ve mümkünse kontrolleri bölmeyi önerin.

7) UX ve Güvenlik

Payee benzeri doğrulamanın onaylanması: PayID Adının görüntülenmesi alıcı hatası riskini azaltır.
2FA ve cihaz, yetkilendirme sırasında ödeme yapan kişinin bankasında bağlanır.
Antifraud/hız: bankaların kendi kuralları vardır; Olası "yumuşak" başarısızlıkları düşünün.
Şeffaflık: UTR/time/amount/purpose + support contacts ile görüşün.
Fallback: Deeplink açılmadıysa, PayID kopyalama, statik QR ve talimatlar sunun.

8) İadeler ve anlaşmazlıklar

Kart anlamında Chargers yoktur. İade, satıcıdan ödeme yapan kişiye orijinal UTR/OrderId referanslı yeni bir kredi işlemidir.
Raporlarda kısmi geri dönüşleri ve tam izlenebilirliği destekleyin.
Anlaşmazlıklar bankalar/PSP'ler ve destek düzenlemeleri ile çözülür; Lay SLA ve kanıt toplama (sipariş günlüğü, teslimat, yazışma).

9) Tüccar Entegrasyonu: Seçenekler

1. Statik PayID

Hızlı başlayın, minimum gelişim.
Riskler: insan faktörü (miktar/yorum girme), daha zayıf analitik.

2. Dinamik QR/deeplink

Siparişe göre üretim: sabit miktar, orderId, havale.
Daha iyi sipariş başına keşif, daha az hata, daha yüksek dönüşüm.

3. Ödeme Talebi

Satıcıdan "fatura" - ödeyenden onay.
Faturalama, B2B ve değişken miktarlı hizmetler için kullanışlıdır.

4. PayTo (e-mandalar)

Abonelikler/yinelenen ücretler; Ödeme yapan kişi bankasındaki yetkiyi yönetir.
Onay ekranlarına, limit yönetimine, bildirimlere ihtiyacımız var.

• Web durum kancaları (başarı/başarısızlık/beklemede), tekrarlanan anketler.
• Idempotency tablosu (orderId + sorgu anahtarı).
• UTR/OrderId/zaman/miktar ile mutabakat.
• Geri ödeme API'leri ve ODR prosedürleri.
• Banka/PSP SLA izleme (gecikme, başarı, hata kodları).

10) Mutabakat ve Raporlama (ISO 20022, UTR)

UTR (benzersiz transfer tanımlayıcısı) - ana mutabakat anahtarı; Hem orijinal ödemeyi hem de geri ödemeyi saklayın.
OrderId, cart, customerRef için ISO 20022 atama/havale alanlarını kullanın.
Günlük otomatik keşif ve periyodik tam keşif yapılandırın.
PSP raporları: işlemler, durumlar, PayTo biletleri, iadeler, sapmalar.

11) Tarifeler ve maliyetler

NPP/PayID için kart şemalarında olduğu gibi klasik MDR yoktur, ancak satın alma, PayTo modülleri, raporlama, SLA paketleri için sağlayıcı ücretleri vardır.
Destek/anlaşmazlıklar, dolandırıcılıkla mücadele, QR üretimi ve deeplink sayfası barındırma maliyetlerini göz önünde bulundurun.

12) Çevrimdışı seçenekler ve QR

Tüccar tarafından sunulan QR (dinamik): POS/ödeme için en uygun; Miktar ve meta veriler kodda korunur.
Statik QR: PayID'yi miktar olmadan kodlar; Miktarı manuel olarak girin.
Print-on-check/on the plate: Küçük işletmeler için izin verilir, ancak uzlaşma için daha kötüdür.

13) Uyum, AML/CTF ve Gizlilik

AML/CTF (AUSTRAC), işlem/bilet günlüğü depolama, PSP'deki KYC seviyelerine uyun.
PSP düzeyinde yaptırım/sahtekarlık taraması, Hız kuralları, anomali izleme uygulayın.
PayID verilerini minimizasyon ilkelerine göre işlemek; Yalnızca UX ve denetim için gerekenleri gösterin.

14) Yüksek riskli özellikler (iGaming dahil)

Avustralya'daki bankalar/PSP'ler, bireysel kategorileri kendi risk politikalarında kısıtlayabilir.
Azaltılmış limitler, güçlendirilmiş KYC ve ek işlem analizleri bekleyin.
Mevduat/geri ödemeler için alternatif raylar ve net bir iade süreci planlayın.

15) NPP/PayID Ağ Geçidi servis mimarisi

API: 'PaymentIntent', 'generateDynamicQR', 'requestToPay', 'createPayToMandate', 'refund', 'reconnile', 'webhook'.
Güvenilirlik: Katlanarak geri ödeme, idempotency, olay tekilleştirme.
Gözlemlenebilirlik: metrikler (başarı/başarısızlık/gecikme), izler, SLA bankalarındaki uyarılar.
Güvenlik: Web kancalarının HMAC imzası, allowlist IP, sırların döndürülmesi, denetim günlüğü.
Veriler: bankalar/kanallar tarafından bireysel limit dizinleri, PayTo yetki durumları, UTR kartı.

16) Çıktı kontrol listesi

1. Banka/PSP'den ticari PayID (veya PayID havuzu) alın.
2. Bir akış seçin: dinamik QR/deeplink, Request-to-Pay ve/veya PayTo.
3. Web kancaları, idempotans ve bir bilet masası uygulayın.
4. UTR yönelimli keşif (günlük + tam), yanlış hizalama ile uyarıları etkinleştirin.
5. İade akışını çalıştır (tam/kısmi), ODR günlükleri.
6. UX limit ekranları, PayID Name önizlemesi, anlaşılabilir hatalar ekleyin.
7. SLA izleme ve sağlayıcı panolarını ayarlayın.
8. Farklı veren bankalar ve PayTo senaryoları ile uçtan uca testler yapın.

Özgeçmiş Özeti

Bir kerelik ödemeler için, zengin meta verilerle dinamik QR/deeplink üzerine bahis yapın.
Abonelikler ve yinelenen ödemeler için, şeffaf UX yönetimi ile PayTo biletlerini kullanın.
Kod sınırlarını zorlamayın: banka/PSP yapılandırmalarını ve güncellemelerini saklayın.
UTR mutabakatı, ayrıntılı günlük kaydı ve SLA tarafından uyarı etrafında bir süreç oluşturun.