PayID أستراليا: تدفقات NPP

1) السياق: NPP و PayID

NPP (منصة المدفوعات الجديدة) - البنية التحتية الوطنية للدفع الفوري في أستراليا (24/7/365) مع تسويات في الوقت الفعلي ورسالة غنية من ISO 20022. PayID هي طبقة عناوين أعلى NPP، والتي تسمح لك بالدفع ليس عن طريق BSB/Account، ولكن عن طريق الاسم المستعار «البشري»: رقم الهاتف أو البريد الإلكتروني أو ABN/ACN أو معرف المنظمة.

• قابلية التشغيل البيني: أي مشارك في برنامج العمل الوطني ↔ أي بنوك إصدار.
• عنوان الاسم المستعار: يرى الدافع اسم PayID قبل التأكيد (ضد التوجيه الخاطئ).
• اللحظة والنهاية: يتم عرض الائتمان على حساب التاجر على الفور ؛ العودة - عملية منفصلة.
• بيانات الدفع: ISO 20022 مع تحويل مناسب (الغرض من الدفع، الطلب، إلخ).

2) الأعضاء والأدوار

NPP/Schema Routing and Rules

بنك الدافع (Payer FI): مصادقة العميل، ومكافحة الاحتيال، وإرسال رسالة.
مصرف Payee/مستحوذ (Payee FI): قبول القرض والإشعارات والإبلاغ.
PSP/fintech: تطبيقات الخطوط الأمامية، SDKs، التقارير والتسويات للتجار.
التاجر: يحمل PayID (أو التفاصيل المصرفية)، ويولد طلبًا/رابطًا إلى الدافع.

3) PayIDs

أنواع PayID: الهاتف المحمول، البريد الإلكتروني، ABN/ACN، معرف المنظمة.

• يرتبط كل PayID باسم PayID الذي يراه الدافع قبل التأكيد.
• يمكن أن يحتوي حساب واحد على العديد من PayIDs ؛ وتدعم إجراءات الهجرة إمكانية النقل عبر المصارف.
• ABN/ACN-PayID مناسبة للأعمال: من الأسهل مطابقة ملف تعريف الشركة.

4) تدفقات الدفع الأساسية (NPP/PayID)

P2P (دفع): يدخل الدافع/يمسح PayID الخاص بالمدفوع → ويرى اسم PayID → يؤكد → الائتمان على الفور.
P2M (دفع): ينشر التاجر PayID أو يصدر deeplink/QR مع مبلغ مملوء مسبقًا وبيانات وصفية.
طلب الدفع (التحصيل): يقدم التاجر طلب الدفع ؛ يؤكد المستخدم في التطبيق المصرفي.

• للتجارة الإلكترونية، استخدم deeplink/QR بمبلغ ثابت وطلب Id.
• بالنسبة إلى غير متصل بالإنترنت، فإن PayID الثابت مقبول، لكن QR الديناميكي لكل طلب أفضل.

5) PayTo: الولايات الإلكترونية والعمليات التلقائية

• يقوم التاجر/PSP بإنشاء تذكرة مع معلمات (دافع، حساب، حدود، تردد، وصف).
• يأذن الدافع بالتفويض في طلبه المصرفي.
• وتنفذ عمليات الشطب الأخرى تلقائيا في إطار شروط الولاية دون توثيق يدوي لكل خطوة.
• السيناريوهات: الاشتراكات، المرافق/الاتصالات، الخطط العادية، الفواتير القائمة على الاستخدام مع الحد الأقصى.

• أظهر للمستخدم حدود التذكرة وتكرارها وتاريخ الشحنة التالية.
• احتفظ بلوحة التحكم في التذاكر (توقف مؤقتًا/إلغاء/تحديث) وخطافات الويب حول الحالات.

6) الحدود ومراقبة المخاطر

• لكل معاملة/يوميًا: قد تختلف عتبات البنك لـ NPP/PayID وتختلف.
• المستلمون الجدد: غالبًا ما تكون حدود البداية و/أو سرعة الغالق المخفضة سارية المفعول.
• السياسات القاطعة: قد يكون لدى فرادى مراكز التنسيق الإداري/القطاعات تشديد.
• تذاكر PayTo: يتم تحديد الحدود في التذكرة نفسها (المبلغ والفترة والحد الأقصى للشطب).

• لا ترمز صلب كميات - احتفظ بدليل الحدود وقم بالتحديث بانتظام.
• في الواجهة، حذر من الفائض المحتمل واقترح تقسيم الشيكات، إن أمكن.

7) UX والأمن

تأكيد التحقق مثل Payee: عرض اسم PayID يقلل من خطر خطأ المستلم.
2FA والجهاز الملزم في بنك الدافع في وقت الإذن.
Antifraud/velocity: للمصارف قواعدها الخاصة ؛ النظر في الإخفاقات «الناعمة» المحتملة.
الشفافية: تحقق من اتصالات الدعم مع UTR/time/cand/purpose +.
الاحتياطي: إذا لم يتم فتح deeplink، فاقدم نسخ PayID و QR والتعليمات الثابتة.

8) العودة والنزاعات

لا توجد أجهزة شحن بمعنى البطاقة. العائد هو صفقة ائتمان جديدة من التاجر إلى الدافع بالإشارة إلى UTR/OrderId الأصلي.
دعم العودة الجزئية وإمكانية التتبع الكامل في التقارير.
تسوية المنازعات من خلال المصارف/شراكات القطاع الخاص ولوائح الدعم ؛ LLA وجمع الأدلة (سجل الطلبات والتسليم والمراسلات).

9) التكامل التجاري: الخيارات

1. Static PayID

ابدأ بسرعة، الحد الأدنى من التطوير.
المخاطر: عامل بشري (إدخال الكمية/التعليق)، تحليلات أضعف.

2. ديناميكية QR/deeplink

التوليد حسب الطلب: المبلغ الثابت، الطلب، التحويل.
أفضل لكل طلب، وأخطاء أقل، وتحويل أعلى.

3. طلب الدفع

«الفاتورة» من التاجر → تأكيد من دافع.
مفيد لإصدار الفواتير وخدمات B2B والمبالغ المتغيرة.

4. PayTo (الولايات الإلكترونية)

الاشتراكات/الرسوم المتكررة ؛ دافع يدير التفويض في مصرفهم.
نحن بحاجة إلى شاشات الموافقة، وإدارة الحدود، والإشعارات قبل الشطب.

• خطافات الويب للمكانة (النجاح/الفشل/المعلقة)، استطلاعات متكررة بالتراجع.
• جدول الخصوصية (OrderId + query key).
• تسوية بواسطة UTR/OrderId/time/auth.
• رد واجهات برمجة التطبيقات وإجراءات تسوية المنازعات بالاتصال الحاسوبي المباشر.
• رصد البنك/PSP SLA (الكمون والنجاح ورموز الخطأ).

10) المصالحة والإبلاغ (ISO 20022، UTR)

UTR (معرف نقل فريد) - مفتاح التسوية الرئيسي ؛ احتفظ بالدفعة الأصلية والعائد.
استخدام ISO 20022 حقول التخصيص/التحويل للطلب.
قم بتهيئة الاستطلاع التلقائي اليومي والاستطلاع الكامل الدوري.
تقارير PSP: المعاملات، والحالات، وتذاكر PayTo، والعائدات، والانحرافات.

11) التعريفات والتكاليف

بالنسبة لـ NPP/PayID، لا يوجد MDR كلاسيكي كما هو الحال في مخططات البطاقات، ومع ذلك، هناك رسوم مزود للحصول على وحدات PayTo والإبلاغ وحزم SLA.
ضع في اعتبارك تكاليف الدعم/المنازعات ومكافحة الاحتيال وتوليد الاستجابة السريعة واستضافة الصفحات.

12) خيارات غير متصلة بالإنترنت و QR

QR (ديناميكي) مقدم من التاجر: مثالي لنظام التشغيل/الخروج ؛ والبيانات الوصفية محمية في رمز.
الاستجابة السريعة الثابتة: تشفر PayID بدون مبلغ ؛ أدخل المبلغ يدويًا.
الطباعة عند التحقق/على اللوحة: مسموح بها للشركات الصغيرة، ولكنها أسوأ للمصالحة.

13) الامتثال و AML/CTF والسرية

الامتثال لـ AML/CTF (AUSTRAC)، وتخزين سجل المعاملات/التذاكر، ومستويات KYC في PSP.
تطبيق فحص العقوبات/الاحتيال على مستوى PSP، وقواعد Velocity، ومراقبة الشذوذ.
معالجة بيانات PayID وفقًا لمبادئ التقليل إلى أدنى حد ؛ أظهر فقط ما هو مطلوب لـ UX والتدقيق.

14) الميزات عالية الخطورة (بما في ذلك iGaming)

قد تقيد البنوك/PSPs في أستراليا الفئات الفردية على سياسات المخاطر الخاصة بها.
توقع حدودًا مخفضة، وتعزيز KYC وتحليلات معاملات إضافية.
تخطيط مسارات بديلة للودائع/المدفوعات وعملية إرجاع واضحة.

15) بنية خدمة NPP/PayID Gateway

API: "إنشاء نية الدفع"، "إنشاء DynamicQR"، "طلب الدفع"، "إنشاء PayToMandit'،" استرداد "،" تسوية "،" webhook ".
الموثوقية: إعادة الدرس بشكل كبير، الخصوصية، تفريغ الحدث.
إمكانية الرصد: المقاييس (النجاح/الفشل/زمن الانتقال)، الآثار، التنبيهات على مصارف SLA.
الأمان: توقيع HMAC لخطافات الويب، IP allowist، تدوير الأسرار، سجل التدقيق.
البيانات: أدلة فردية للحدود حسب البنوك/القنوات، PayTo تفوض الأوضاع، بطاقة UTR.

16) قائمة المخرجات المرجعية

1. احصل على تاجر PayID (أو تجمع PayID) من البنك/PSP.
2. حدد دفق: QR/deeplink الديناميكي، طلب الدفع و/أو PayTo.
3. قم بتنفيذ خطافات الويب والغباء وطاولة التذاكر.
4. مكّن recon الموجه إلى UTR (يوميًا + ممتلئ)، التنبيهات عن طريق الاختلال.
5. تشغيل تدفق استرداد (كامل/جزئي)، سجلات تسوية المنازعات بالاتصال الحاسوبي المباشر.
6. أضف شاشات حد UX، معاينة اسم PayID، أخطاء مفهومة.
7. إنشاء لوحات مراقبة ومزود ل SLA.
8. إجراء اختبارات شاملة مع بنوك إصدار مختلفة وسيناريوهات PayTo.

ملخص السيرة الذاتية

للمدفوعات لمرة واحدة، راهن على QR/deeplink الديناميكي مع البيانات الوصفية الغنية.
للاشتراكات والمدفوعات المتكررة، استخدم تذاكر PayTo مع إدارة UX شفافة.
لا تحد من الرمز الصلب: احتفظ بتكوينات البنك/PSP وتحديثها.
بناء عملية حول تسوية UTR، والتسجيل التفصيلي والتنبيه من قبل SLA.